System and method for facilitating secure self payment transactions of retail goods

ABSTRACT

Disclosed herein are various embodiments for systems and methods for self-payment and verification of the purchase of retail goods and services. According to an embodiment of the invention, a method for verifying the purchase using a mobile electronic device in wireless communication with a payment verification system and a code generating system is provided, the method comprising the steps of: receiving from a consumer information identifying an item for purchase; receiving from a consumer information identifying payment means for purchasing the item for purchase; processing the information identifying the item for purchase and information identifying payment means and generating a unique QR code indicating a purchase of the item; sending the unique QR code to a mobile device for display by a consumer to the vendor of the item for purchase.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of, and claims the benefit of, U.S.patent application Ser. No. 14/189,623 filed on Feb. 25, 2014, which isa continuation of U.S. patent application Ser. No. 13/801,132 filed onMar. 13, 2013 (now U.S. Pat. No. 8,720,771), which claims the benefit ofU.S. Provisional Patent Application No. 61/615,140 filed Mar. 23, 2012;U.S. Provisional Patent Application No. 61/732,268 filed Nov. 30, 2012;and U.S. Provisional Patent Application No. 61/751,653 filed Jan. 11,2013; the disclosures of which are hereby incorporated by reference intheir entirety.

FIELD OF THE INVENTION

The present invention relates generally to systems and methods for thepayment and verification of payment of goods and services for use withmobile devices. More specifically, the invention relates to systems andmethods for paying and verifying the payment of goods and services foruse with mobile devices wherein a unique coded receipt is generated toverify the valid purchase of goods and services.

BACKGROUND OF THE INVENTION

Retailers generally have the same goals: to increase sales and profit.Retailers can increase revenue and profit by acquiring more customers,and by persuading each customer to buy more products, more expensiveproducts, or more profitable products. Retailers generally focus ontheir customers in order to increase sales. They try to improve customerservice and offer a unique and pleasant shopping experience. Customersrespond positively to businesses that try to understand their needs, andwho offer better and faster services.

Some factors affecting in-store sales are the number of customerswilling to purchase a product at the store and the time that is requiredto process customers' purchases at the store. Time is often a criticalfactor. Customers do not like to wait.

If a consumer visits a store looking for a particular product, he or shehas to: find a store, physically access the store, find the desiredproducts in the store, interact with a sales associate, and thenpurchase his or her product. To complete a purchase, the consumer has tofirst find a checkout inside a store, and then visit a register tocomplete his or her purchase. Sometimes this can be a long process, andconsumers may experience a lot of difficulties when they shop and payfor their desired items.

The delays and difficulties associated with locating and purchasing anitem can have a negative effect on a retailer's sales. If customers areforced to wait for assistance to locate or purchase an item, they maybecome frustrated and leave the store without making the purchase,leading to lost revenue. In addition, a customer who leaves due todelays in checking out may fail to return the item to the proper stocklocation, leading to additional overhead. Delays and lack of attentionmay further lead to an overall poor shopping experience, discouragingcustomers from shopping at that store again, These two aspects—beingforced to wait and a poor shopping experiences—can lead to lost salesfor a retailer.

In addition, to complete a purchase transaction, consumers usually mustcarry cash or a debit/credit card. Forgetting a wallet means that aconsumer has to postpone his or her purchase, it is more likely that aconsumer will forget his or her wallet than mobile device when he or sheleaves the home.

Modern technologies are rapidly becoming a part of the connectionbetween customers and retailers, and this new relationship calls for newapproaches. Today, more than four billion people own mobile devices.Many people are moving from standard cell phones to internet-enabledsmart phones, tablets and other e-devices that are as powerful ascomputers. Customers are a click away from buying products. Forcustomers, the benefit is all about convenience. Using moderntechnologies makes life easier. The massive growth of social media,e-commerce and mobile commerce has shifted customers' expectations oftheir shopping and paying experience.

Today there are systems that exist in the marketplace that allow aconsumer to pay for his or her purchase in-aisle, however these systemstypically require the consumer to interact with either amobile-device-carrying personal retail associate that processes thetransaction using the consumers' physical plastic payment card incombination with a proprietary hardware device or that requires theconsumer to stop at a self-service kiosk, scan a code using his or hermobile device at a kiosk and print out a paper receipt verifying thetransaction which is then to be shown by the consumer at the exit to aretail sales associate who would first examine the paper receipt and ifnecessary enter the receipt transaction details to confirm that thetransaction was successful. These systems typically use proprietarysoftware and hardware, such as a mobile device magnetic card or EMV(chip) reader attachment or a kiosk that is used to either take finalpayment or that provides the consumer with a paper receipt which thenneeds to be displayed as the consumer leaves the store. Generallyspeaking, the currently existing systems require the use of a physicalpayment card and/or that requires an interaction with an actual storeassociate to process the payment.

Such existing mobile shopping applications do not provide a complete andsecure solution for in-store mobile payment and self-checkout. Forexample, methods involving visual inspection of a paper receipt arevulnerable to duplication and falsification and generally slow down thecustomer's shopping process.

In view of the above, it would be beneficial to provide a system thatallows a consumer to proceed with a transaction for goods on demand, andto do so in a secure fashion that is acceptable to both the consumer andthe retailer.

SUMMARY OF THE INVENTION

Disclosed herein are various embodiments for systems and methods forfacilitating self-payment and verification of the purchase of retailgoods and services.

According to an embodiment of the invention, a method for verifying thepurchase using a mobile electronic device in wireless communication witha payment verification system and a code generating system is provided,the method comprising the steps of: receiving from a consumerinformation identifying an item for purchase; receiving from a consumerinformation identifying payment means for purchasing the item forpurchase; processing the information identifying the item for purchaseand information identifying payment means and generating a unique QRcode indicating a purchase of the item; sending the unique QR code to amobile device for display by a consumer to the vendor of the item forpurchase.

According to an embodiment of the invention, a computer-implementedmethod is provided for verifying the purchase of goods and servicesbetween a consumer and a retailer, said consumer having a mobile devicecapable of communicating with a server, and said retailer having anelectronic device capable of communicating with the server and with theconsumer's mobile device, the method comprising the following steps:receiving a first set of data from the consumer's mobile device, saidfirst set of data identifying one or more goods or services to bepurchased; receiving a second set of data from the consumer's mobiledevice, said second set of data identifying payment means for thepurchase of said one or more goods or services; creating a data recordin a database representing the purchase of said one or more goods orservices by said consumer; generating in response to the successfulpurchase of said one or more goods or services via the identifiedpayment means a unique code, said unique code associated with said datarecord such that said unique code contains a link to said data record;transmitting said unique code to the consumer's mobile device for use bythe consumer to verify to the retailer the purchase of said one or moregoods or services; and wherein the steps of receiving the first set ofdata, receiving a first set of data, receiving a second set of data,creating a data record, generating a unique code, associating saidunique code, and transmitting said unique code are performed by theserver.

In a related embodiment, the unique code is in the form of a quickresponse (“QR”) code.

In another related embodiment, the data record includes the followingdata: the goods or services purchased, the method of payment used topurchase the goods or services, the date of the purchase, and a consumerID.

In another related embodiment, the step of generating in response to thesuccessful purchase of said one or more goods or services via theidentified means of payment a unique code comprises the steps oftransmitting to a third-party server a request for a unique code, therequest containing information to be embedded in the unique code; andreceiving from the third-party server a unique code in response to thesecond request.

In another related embodiment, the method further comprises the steps ofdetermining whether any of the one or more goods or services identifiedin the first set of data are currently unavailable; and transmitting anotification to the consumer's mobile device indicating whether any ofthe one or more goods or services identified in the first set of dataare currently unavailable.

In another related embodiment, the first set of data is input by theconsumer into the consumer's mobile device when the consumer is outsideof the retailer location containing the goods and services, and themethod further comprises the steps of creating a data entry in the datarecord to indicate the portion of the goods identified in the first setof data that have already been collected from the retailer by theconsumer.

In another related embodiment, the method further comprises thefollowing steps: capturing via the retailer's electronic device saidunique code contained on the consumer's mobile device; verifying thevalidity of the unique code displayed on the consumer's mobile device;and displaying via the retailer device whether or not the unique codedisplayed on the consumer's mobile device is valid.

In another related embodiment, the method further comprises the steps ofretrieving from a database a data record associated with said uniquecode; obtaining from said data record the identity of the goods orservices purchased by the consumer; transmitting to the retailer devicethe goods or services purchased by the consumer; and displaying on theretailer device the goods or services purchased.

In another related embodiment, the retailer's electronic device includesan optical capture device and associated software for processingcaptured images, and the step of reading via the retailer's electronicdevice said unique code comprises optically scanning the unique code.

In another related embodiment, the step of verifying the validity of theunique code displayed on the consumer's mobile device comprisestransmitting said unique code to the server; retrieving embeddedinformation from said unique code; comparing the embedded informationfrom said unique code to entries in a table containing valid purchaseinformation; and indicating whether the embedded information in saidunique code matches an entry in the table containing valid purchaseinformation.

In another embodiment, a system is provided which provides forimplementing the above methods. In particular, a system is provided forverifying the purchase of goods and services between a consumer and aretailer, said consumer having a mobile device capable of communicatingwith one or more servers, the system comprising: a server comprising oneor more processors and a non-transitory storage medium in communicationwith said one or more processors, said non-transitory storage mediumhaving instructions thereon which, when executed by the one or moreprocessors, causes the one or more processors to execute the steps of:receiving a first set of data from the consumer's mobile device, saidfirst set of data identifying one or more goods or services to bepurchased; receiving a second set of data from the consumer's mobiledevice, said second set of data identifying payment means for thepurchase of said one or more goods or services; creating a data recordin a database representing the purchase of said one or more goods orservices by said consumer; generating in response to the successfulpurchase of said one or more goods or services via the identifiedpayment means a unique code, said unique code associated with said datarecord such that said unique code contains a link to said data record;transmitting said unique code to the consumer's mobile device for use bythe consumer to verify to the retailer the purchase of said one or moregoods or services.

In another embodiment, a computer-implemented method is provided forverifying the purchase of goods and services between a consumer and aretailer, said consumer having a mobile device capable of communicatingwith a server, and said retailer having an electronic device capable ofcommunicating with the consumer's mobile device and with the server, themethod comprising the following steps: scanning a code displayed on theconsumer's mobile device; transmitting a request to the server to verifythat the code displayed on the consumer's mobile device is valid:receiving a response from the server indicating whether the codedisplayed on the consumer's mobile device represents a valid purchase;displaying whether or not the code displayed on the consumer's mobiledevice is valid; and wherein the steps of reading a code, transmitting arequest, receiving a response, and displaying are performed by theelectronic device.

In a related embodiment, the code is in the form of a quick response(“QR”) code.

In a related embodiment, the data record includes the following data:the goods or services purchased, the method of payment used to purchasethe goods or services, the date of the purchase, and a consumer ID.

In a related embodiment, the method further comprises the steps ofreceiving from the server a list of goods or services purchased by theconsumer associated with the code; and displaying on the retailerelectronic device the goods or services purchased.

In another embodiment, a system is provided which provides forimplementing the above methods. In particular, a system is provided forverifying the purchase of goods and services between a consumer and aretailer, said consumer having a mobile device capable of communicatingwith a server, the system comprising: a retailer electronic devicecomprising one or more processors and a non-transitory storage medium incommunication with said one or more processors, said non-transitorystorage medium having instructions thereon which, when executed by theone or more processors, cause the one or more processors to execute thesteps of: scanning a code displayed on the consumer's mobile device;transmitting a request to the server to verify that the code displayedon the consumer's mobile device is valid; and receiving a response fromthe server indicating whether the code displayed on the consumer'smobile device represents a valid purchase; displaying whether or not thecode displayed on the consumer's mobile device is valid.

These and other aspects and advantages will become apparent to those ofordinary skill in the art by reading the following detailed description,with reference where appropriate to the accompanying drawings. While thepresent invention is capable of being embodied in various forms, forsimplicity and illustrative purposes, the principles of the inventionare described by referring to several embodiments thereof It isunderstood, however, that the present disclosure is to be considered asan exemplification of the claimed subject matter, and is not intended tolimit the appended claims to the specific embodiments illustrated. Itwill be apparent to one of ordinary skill in the art that the inventionmay be practiced without limitation to these specific details. In otherinstances, well-known methods and structures have not been described indetail so as not to unnecessarily obscure the invention. Further, itshould be understood that the foregoing summary is merely illustrativeand is not intended to limit in any manner the scope or range ofequivalents to which the appended claims are lawfully entitled.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is described below in connection with the followingillustrative figures, wherein like reference numbers refer to likeelements throughout, and wherein:

FIG. 1 is a high-level communications flow diagram showing the partiesinvolved and their relationships in the process of performing a secureself-payment transaction, according to an embodiment of the invention;

FIG. 1A is a high-level communications flow diagram showing the partiesinvolved and their relationships in the process of performing highersecurity steps in the secure self-payment transaction involving theretailer server, according to an embodiment of the invention;

FIG. 2 is a process flow diagram showing the steps for a secureself-payment transaction, according to an embodiment of the invention;

FIG. 3 is a process flow diagram showing the consumer steps tocompleting an in-aisle secure self-payment transaction, according to anembodiment of the invention;

FIGS. 4A and 4B are a process flow diagram showing certain stepsundertaken in the self-payment transaction using a secure self-paymentapplication and related system components, according to an embodiment ofthe invention;

FIG. 4C is a process flow diagram showing certain steps undertaken inthe secure self-payment transaction using a secure self-paymentapplication and related system components, according to anotherembodiment of the invention;

FIG. 5A is a relational diagram showing the interactions betweendatabases and system components used in the self-payment transactionsystem, according to an embodiment of the invention;

FIG. 5B is a relational diagram showing the interactions betweendatabases and system components used in the self-payment system andmethod, according to another embodiment of the invention;

FIG. 6 is a diagram illustrating the devices that may be used in thesecure self-payment system and method, according to an embodiment of theinvention;

FIG. 7 is a diagram showing the process steps involved in fulfilling arequest from the self-payment web API to the retailer network, accordingto an embodiment of the invention;

FIG. 8 is a diagram showing the process steps involved in fulfilling arequest from a consumer device submitted to the self-payment systemserver, according to an embodiment of the invention;

FIG. 9 is a diagram showing components of a consumer mobile device to beused with the secure self-payment system and method, according to anembodiment of the invention;

FIG. 10 is a diagram of a type of retailer point-of-service (“POS”)system which may be used with the secure self-payment system and method,according to an embodiment of the invention;

FIG. 11 is a diagram of a type of retailer network which may be usedwith the secure self-payment system and method, according to anembodiment of the invention;

FIG. 12 is a diagram of the service provider network to be used with thesecure self-payment system and method, according to an embodiment of theinvention;

FIG. 13 is a screenshot diagram demonstrating the process involved insuccessfully verifying a consumer purchase through use of the retailerself-payment verification application, according to an embodiment of theinvention;

FIG. 14 is an example menu interface which may be displayed on theconsumer's device via the consumer's secure self-payment applicationaccording to an embodiment of the invention;

FIG. 15 is an example payment method interface which may be displayed onthe consumer's device via the consumer's secure self-paymentapplication, according to an embodiment of the invention;

FIG. 16 is an example QR-coded receipt as displayed on the consumer'sdevice via the consumer's secure self-payment application, according toan embodiment of the invention;

FIG. 17 is an example device lock screen displayed on the consumer'smobile device when the consumer's secure self-payment application isintegrated with Apple Passbook, according to an embodiment of theinvention;

FIG. 18 is an example interface displayed on the consumer's mobiledevice and viewed in the Apple Passbook app when the consumer's secureself-payment application is integrated with Apple Passbook, according toan embodiment of the invention; and

FIG. 19 is an example QR code illustrating certain characteristicsthereof, according to an embodiment of the invention.

DETAILED DESCRIPTION

Described herein are systems and methods for facilitating in-store andmobile retail purchases for goods and services, including a paymentverification process that utilizes the consumer's mobile device. As partof the systems and methods, a consumer can use the secure self-paymentsystem and method described herein which may be embodied in software(web, application software (“app”), or otherwise) to add itemsdesignated with a barcode or other identifying feature to a virtualshopping cart and to purchase these items while in-store without theneed to wait in a traditional checkout line. The self-payment systemincludes a consumer-facing self-payment application (or self-payment“app”), a retailer-facing verification application (or verification“app”) a service provider web API that uses proprietary as well asthird-party functionality, and a service provider server.

The self-payment systems and methods described herein do not require aretailer to utilize third-party proprietary hardware systems andinteractions. Moreover, the self-payment systems and methods describedherein give the consumer control over where and when payment isperformed in-store as well as control over the handling of his or herpayment at every step of the purchase process. There is no need for liveinteraction with a retailer for the purpose of taking payment, which mayintroduce delays and result in frustration to the consumer. Instead, theconsumer conducts the payment transaction at his or her leisure using aself-payment consumer application installed on the consumers' ownpersonal mobile device.

The payment processing step of the self-payment application may involvea variety of third-party payment processors. This is due to the factthat while a service provider may have preferred processing partners, agiven retailer may be incompatible or unwilling to use certain partner'sservices. As a result, the selection of a third-party payment processorand the corresponding method of processing payments is subject to theparticular needs of the service provider and its retail partner. Themethod of payment processing selected does not affect the overall secureself-payment application.

Unlike existing services, the verification component described hereindoes not require a manual keyed entry of a purchase ID by the retailerinto a point-of-service (“POS”) system or other similar device orinteraction with a physical kiosk to print a physical receipt.

According to the systems and methods described herein, upon payment ofgoods or services, the service provider provides the consumer with atoken or code that can be provided to the retailer to verify thepurchase of such goods or services. In the preferred embodiment, theverification portion of the payment process uses a QR-coded digitalreceipt to be displayed on the consumer's mobile device. This QR-codeddigital receipt is scanned for verification by the retailer through theuse of a companion verification application residing on the retailer'selectronic device. In the preferred embodiment, the retailerverification component is fully mobile and may be used by a liveassociate anywhere in-store, such as at a designated service desk, nearthe exit doors, or throughout the store by an associate while walkingaround tending to shoppers and performing daily tasks. Additionally oralternatively, the retailer verification application is added intoexisting hardware such as a kiosk or other stationary hardware throughthe service provider's application programming interface, or “API.”

The verification component of the secure self-payment systems andmethods described herein are used as part of retailer loss preventioninitiatives. In particular, the verification process of the secureself-payment systems and methods described herein is designed tocomplement a retailer's existing spot check procedures. A spot checkprocedure is one in which the retailer physically or visually inspectsthe consumer or his or her purchase items and receipt after thetransaction is conducted to ensure that the consumer is not engaging intheft of goods or services. The most common method of a retailer spotcheck procedure is performed at the exit of a store and traditionallyinvolves the retail associate physically inspecting a paper receipt andlooking through a consumer's shopping bag. As discussed below, theretailer verification application can automatically verify a consumer'stransaction based on the code displayed on the consumer's mobile device.This automatic verification helps to eliminate human error in the firstinstance, in addition, in certain embodiments the retailer verificationapplication provides visual cues to the retail associate if the secureself-payment system cannot retrieve a legitimate data recordcorresponding to the displayed QR coded receipt as shown on theconsumer's mobile device. These visual cues can further supplement aretailer's fraud prevention process.

In the preferred embodiment the communications involved in the secureself-payment process are exchanged between four main parties: theconsumer, the retailer, the application service provider, andthird-parties that provide various services related to the self-paymentapplication, such as payment processing, payment card data capture,product barcode information capture, and social media updates. Methodsof communication include the use of both wired and wireless networksusing well-known standards and protocols. Communications involved in thesecure self-payment process also include real world physicalinteractions between the consumer-facing self-payment application andthe retailer-facing verification application or other compatible device,and include such interactions directed to capturing informationdisplayed or transmitted by these devices.

In the preferred embodiment, the self-payment application is one of 21shopper activity-based software modules that comprise a suite of whitelabel branded mobile shopping “apps” (i.e., software programs)brand-customized for an individual retailer. Alternatively, theself-payment application is the only module in the suite of apps.

In another embodiment, in addition or as an alternative to being part ofa separate suite of apps for the consumer mobile device, theself-payment application is included in a third-party app through a webinterface. The self-payment application is also designed to work withother third-party services for functions relating to both core andoptional features. In those embodiments Where the service provider makesits web API available to third parties, some features and functions maybe modified by the third-party, but the payment verification aspectremains intact.

Communications Between Parties

FIG. 1 provides a high-level diagram showing the communications betweenparties in the self-payment application, according to an embodimentwhere the retailer operates a semi-open network. FIG. 1 explains thecommunication breakdown and parties involved in both the core andoptional self-payment application functions and activities. Accordingly,not all of the communications need be present in all embodiments of theself-secure systems and methods described herein.

As shown in FIG. 1, the consumer 102 is the customer, shopper or otheruser running the self-payment application on his or her mobile device.The mobile device is described in greater detail in the sections below.The consumer may be simultaneously running other background processes orsupporting software. The retailer 104 is the party who sells goods andservices and who operates the purchase verification on the retailer'selectronic device, which is typically also a mobile device. Theretailer's electronic device is described in greater detail in thesections below. The service provider 106 is the party that provides thesecure self-payment web API, and that makes available the consumerself-payment application and the companion verification application usedby the retailer. In certain of the illustrative examples describedherein, the service provider is referred to as “SelfPay.” For purposesrelating to communication and networking, the web API is the wide areanetwork accessible programming interface through which the self-paymentapplication components are accessed. This web API can be accessed by theservice provider through the self-payment app or other serviceprovider-developed apps, as well as by third-party software developed bya third-party.

The third-party 108 represents the party or parties that are being usedto facilitate specific functions of the self-payment application thatare not performed by the consumer self-payment app, the retailercompanion app, or the web API. These functions do not need to heperformed in-app by the self-payment application, and may instead beperformed using other hardware and software and then relayed to theself-payment application through a network for final confirmation orfeedback. As used herein, the term “in-app” means that the function orfunctions are performed by or communicated through the specifiedapplication, or “app.” One example of a function performed by athird-party 108 is the processing of credit card payments.Alternatively, all or portions of these functions may be internalizedinto a web API.

The manner of communication, including the protocol and data content ofthe communication, may vary depending on the purpose of thecommunication and the respective capabilities of the sending andreceiving party. As used herein, the terms “two-way connection” or“two-way data connection” are generally used to refer to any of thefollowing:

-   -   (i) a connection initiated by one party with a required or        expected response;    -   (ii) a connection initiated by one party which is one way, but        in practice is responded to with a one-way connection; or    -   (iii) a protocol by which one party sends a regular request for        information and receives a response.        As used herein, the terms “one-way connection” or “one-way data        connection” are generally used to refer to any of the following:    -   (i) a connection initiated by one party that does not require a        non-trivial response note that most one-way connection protocols        are at least trivially two-way in that they generally require an        acknowledgement response to establish communications; for        example, a consumer using a device using NFC (near field        communications) may initiate a one-way send of a verification        URL, but initiating this one-way send requires two-way        communications to set up such communications;    -   (ii) a connection initiated by one party that does not require a        two-way connection; or    -   (iii) a connection, which because of the nature of the protocol        by which the connection occurs, sends information in only one        direction an example of such a one way connection would be a QR        code-based information exchange from one device to another        wherein the QR code is scanned.

As illustrated in FIG. 1, the consumer 102 and the retailer 104communicate via a one-way data connection 110 involving the use of theconsumer's self-payment application and the retailer's verificationapplication for the purposes of verifying a consumer's purchase. In thepreferred embodiment, one-way data connection 110 refers to use of theretailer's electronic device to capture information from theself-payment application on the consumer's device. The act of capturingthis information can encompass a variety of methods, including scanningor reading a code containing this information, as well as receiving awireless transmission of the information. In the preferred embodiment,the information comprises a token that is associated with a data recordindicative of a transaction, information is embedded in a QR codedisplayed in-app on the consumer's mobile device, and the one-way dataconnection 110 involves scanning the QR code through the use of theretailer's companion verification app and the device's scanningcomponent, such as a camera or laser code reader. More specifically,this connection is likely conducted by the following method: the code isdisplayed on the consumer's mobile device through the use of the secureself-payment application, the code is then optically scanned by thescanning component of the retailer's electronic device through the useof the retailer's verification application. Alternatively oradditionally, the capturing of the code can be performed by otherhardware, not necessarily running the verification application, but withaccess to service provider's web API, such as a POS system or otherhardware with a camera or laser code reader. In other embodiments, theQR code itself is not scanned or read; instead the underlying linkencoded in the QR code is captured. An example would be through the useof NFC (near-field communication) technology, in which case connection110 is used to capture the necessary information through a contactlessterminal or NFC-enabled device. As described in greater detail below,the one-way data connection 110 is used verify consumer's purchasethrough the use of a unique code, such as a unique QR code, displayed onthe consumer's mobile device. This communication link 110 is used topass information that is secured and verified by communication link 114.

In some embodiments where the technology or implementation so requires,connection 110 is a two-way data connection. For example, where thetechnology used for connection 110 is based on NFC technology, a two-waydata connection may be required to establish the communication link.

The consumer 102 and the self-payment service provider 106 communicatevia a two-way data connection 112. This two-way data connection isperformed over a network (such as a wireless network, a wired network,or a combination thereof) in communication with the consumer's mobiledevice on the one hand and the one or more servers that comprise theservice provider network and host the service provider's web API.Information exchanged via two-way data connection 112 includesconsumer-specific information such as consumer name, address, paymentinformation, and optional social network aliases. Other information,including information relevant to the parties involved in thetransaction as well as information unrelated to these parties, can alsobe exchanged via two-way communication 112 in accordance with thevarious embodiments described herein. In the preferred embodiment,two-way communication 112 is primarily initiated by the consumer'smobile device and the service provider network responds by sendingrequested information back to the consumer's mobile device.

The service provider 106 and the retailer 104 communicate via a two-waydata connection 114. This two-way data connection is performed over anetwork between retailer components (such as the retailer's network, theretailer's electronic devices and the purchase applications runningthereon, and the retailer's software or other source code on theretailer's network servers) and third-party servers informationexchanged via two-way data connection 114 includes database-specificinformation such as inventory updates, pricing, accounts receivable oremployee identification. In the preferred embodiment, this two-waycommunication is initiated at regular time intervals by the retailer andthe information from the service provider is sent entirely in responseto these queries. This technique of periodically initiatingcommunications with a server to receive updated information is commonlyreferred to in the industry as “polling.”

Other information, whether relevant to the parties involved in thetransaction, can also be exchanged via two-way communication 114 inaccordance with the various embodiments described herein. The mostcommon use of connection 114 is for purposes relating to purchaseverification following the communication of information from theconsumer to the retailer via connection 110. As noted above, throughconnection 110 the consumer's mobile device communicates information tothe retailer's electronic device, and in the preferred embodiment theconsumer's mobile, device displays a QR code and the retailer'sverification app is used to scan the QR code displayed on the consumers'mobile device. Using two-way communication 114, the retailer looks for amatching data record to the QR code through the use of the serviceprovider's web API and if a match is found, the service provider's webAPI retrieves the associated purchase information in the data recordfrom the service provider for display on the retailer's electronicdevice to be used in accordance with the retailer's loss preventioninitiatives.

The consumer 102 and one or more third-parties 108 communicate via atwo-way connection 116 that allows the consumer's self-paymentapplication (or other source code) operating on the consumer's mobiledevice to interact with third-party systems in order to achieve avariety of different functions. Examples of such functions include cardrecognition performed through the device camera, social mediaactivities, or other communications. This connection 116 can be internalto the operating system (with installed source code) for a softwaredevelopment kit (SDK). Communications over connection 116 may alsoutilize a polling technique for periodic transfers of information.Additionally or alternatively, communications over connection 116 can beinitiated by the consumer device or be initiated remotely. The preferredembodiment uses a combination of native software and consumer deviceinitiated communications for connection 116, although the exactimplementation of connection 116 depends on the specific implementationdetails of the third party service.

The retailer 104 and the third-party 108 communicate via a two-wayconnection 118 that allows the retailer and third-party to interact in acontrolled and secure fashion with some or all of: the retailer'snetwork the retailer's electronic devices and the purchase applicationsrunning thereon, and the retailer's software or other source code on theretailer's network servers. The reverse is similar for the third-partyby the retailer. Examples of communications via connection 118 includecontrolled API calls over HTTPS (hypertext transfer protocol secure),SSH (secure shell) connections, or other communication protocols. It iscommon for these communications to be based on polling techniques. Inthe preferred embodiment, communications with third party services addedon the retailer side use polling for communications over connection 118,while existing infrastructure would use current implementationtechniques that could vary from retailer to retailer.

The service provider 106 and the third-party 108 communicate via atwo-way connection 120 that allows the web API and the third-party 108to interact in a controlled and secure fashion. Examples ofcommunications over connection 120 include API calls to card scanningservices, payment method or identification verification, email lists,social media communications or other protocols. These connections couldhe internal to the server, or could be passed to another server run bythe service provider which runs the third-party service as software.Communications over connection 120 could also be based onpolling=techniques, or be based on service provider initiated queriesfor specific tasks. The preferred embodiment depends on the specificthird-party service, most typically either software running on aseparate physical or virtualized server, or queries over the webinitiated by the service provider to the third party service.

The consumer 102, retailer 104, service provider 106, and third-party108 are all parties that may be originating, ending or intermediarypoints of specific data or activity. In some cases one party may need tosend information to one or multiple other parties. Likewise, one partymay receive data from another party and then pass on some or all of thereceived data to others. One specific example would be a method ofnotifying the retailer that a consumer has approached or entered itsstore. In one embodiment, location information is provided by way of aGeofence, GPS, or other location service. The communication of thislocation information originates at the consumer 102, is sent to theservice provider 106 via the communication link 112, and is then passedoff to retailer 104 via the communication link 114 to ultimately notifythe retailer that the consumer is in-store. At that point, either theretailer 104 or the service provider 106 sends a welcome or promotionaloffer or message to 102 using the same channels. To the extent that anyof these actions require the use of third-party services, communicationlinks 116, 118, and 120 are utilized as well. Although direct links havebeen shown for some communications, it should be understood that singlecommunications may be accomplished by multi-step communications passingthrough multiple entities either shown or not shown in FIG. 1.

FIG. 1A provides a high-level diagram showing the communications betweenparties in the secure self-payment application, according to anembodiment where the retailer operates a more secure network. Thecommunication method illustrated in FIG. 1A is utilized in thoseembodiments where the retailer requires certain communications to berouted through its own server. This communication method may be usedwith larger retailers which have more strict security protocols and/orrequire a connection to their enterprise software for certain purposes,which may include, but are not limited to, inventory maintenance, salestracking, staff and security monitoring. Some retailers may use thearrangement of FIG. 1A or similar communication arrangement in order tostay compliant with security requirements as specified by certainregulatory bodies, such as, for example, to meet certain the securityrequirements provided by state or federal financial regulations. Thecommunication method shown in FIG. 1A can also be used by the to limitthe number of connections to the retailer's network or to designate theretailer's own restrictions When it comes to allowing specific types ofconnections, networks, IPs, or ISPs are permitted to access the network.FIG. 1A also illustrates that the communication methods generallydescribed with respect to FIG. 1 can be adapted to permit other partiesto be part of the communications exchanged, in accordance with and asrequired by the various embodiments described herein.

The main difference between the communication methods of FIG. 1 and FIG.1A is that some communications in FIG. 1A are linked directly to theretailer while bypassing alternative communications channels. Thecommunications network in FIG. 1A specifically shows retailer network122 and communications exchanged therewith. The retailer network 122 isthe entity that controls access to the retailer's resources andservices. In some embodiments, the retailer network 122 hosts retailerowned content (such as pricing, financial data, images and productdescriptions) and controls and routes traffic and requests for specificpermissions to this content.

Communications between the service provider web API and the retailernetwork 122 occur via a two-way communication link 124 that routestraffic from the service provider web API 106 to the retailer network122. This connection is used when the retailer requires certain controlover or access to specific data, such as when the retailer needs to beable to allow or deny certain connections or permissions for securityreasons or in rare cases when a third-party service query or reply mustpass through a retailer's server. In the preferred embodiment, all thecommunications of link 124 are initiated as outbound communications fromthe retailer network to the web API 122 and operate through a pollingtechnique. This polling technique involves a process wherein theretailer server connects to the service provider network every setperiod of time (for example 5 minutes). This polling technique isextendable to request information at specific non-standard times whereit might be useful. For instance a retail POS terminal might perform anitem look-up and find that the retailer has one item in stock. Usingtwo-way communication link 124, the retail POS terminal immediatelypolls the web API to ensure that the item has not been sold through thesecure self-payment application.

Communications between the retailer network 122 and the third-partyservices 108 occur via a two-way connection link 126. The communicationsexchanged over link 126 may include both verbal communications and data.Link 126 is used by the retailer to pass on specific data on behalf ofthe self-payment service provider or for the retailer's own purposes dueto security related or other issues. Link 126 provides communicationsfrom the retailer to whichever third-party is being used to perform orsupport a specific task. In the preferred embodiment, these connectionsoperate using polling. In addition or alternatively, other communicationtechniques may be used, for example, an inbound connection on a retailerserver.

Overview of Use of Self-Payment Application

FIG. 2 is a flow chart that lists the steps taken in making a purchaseaccording to an embodiment of the secure self-payment applicationdescribed herein. The steps are compartmentalized into individualsections, but may contain additional sub-steps, some of which arediscussed in greater detail with respect to FIG. 3.

At step 202, the consumer accesses the secure self-payment app andregisters for service under the application. The service provider orretailer provides the self-payment app to the consumer for access viaany suitable method, such as by making the app available for download tothe consumer's mobile device over a network via the service provider orretailer's website, or by making the app available for download to theconsumer's mobile device via an “app store” or the like accessible bythe consumer's mobile device. The app provides the consumer with a meansfor providing the service provider with information about the consumerthat will facilitate a secure self-payment transaction. In the preferredembodiment, the app initially prompts the consumer to sign up for anaccount with the service provider by establishing a user name andpassword, and by providing details about the consumer related to thepurchase of goods and services, such as the consumer's name, loyaltycard data, phone, email, billing and shipping addresses, and paymentinformation. In one embodiment, the app further prompts the consumer toprovide secure verification information, such as, but not limited to, apersonal identification number (PIN) or other unique identifier. Inother embodiments, the app permits the consumer to provide informationconcerning the consumer's preferences in using the self-payment app,such as push notifications and location settings. Other aspects of thisstep are discussed below with respect to corresponding elements of FIG.3.

At step 204 the consumer enters a participating physical retail storeand, using the consumer's mobile device, opens the self-payment appcontaining a module directed specifically to performing self-paymentfunctions (referred to herein as the secure self-payment module). Otheraspects of this step are discussed below with respect to correspondingelements in FIG. 3.

At step 206 the consumer provides a set of data that containsidentifying information regarding the goods or services to be purchased.The secure self-payment app may provide the consumer with severaloptions for providing such identifying information. Where the consumer'smobile device is a smart phone or other mobile device equipped withcamera, the app may contain functionality that permits the consumer toscan the bar code or other unique product identifier of an item.Alternatively, the app may contain functionality that prompts theconsumer to enter identifying information manually, or permits aconsumer to select the item from a list of available goods or services.To facilitate the entry of information identifying the goods or servicesto be purchased, the secure self-payment application is capable ofconnecting to and querying a database, either stored with the serviceprovider or the retailer, in such a way so that the consumer can searchor browse for the desired product or service. As further discussedbelow, once the consumer provides identifying information regardinggoods or services to be purchased, the app can provide the consumer withvarious information about the item, such as product availability eitherin-store or on-line, product information and reviews, and permits theconsumer to add the item to the consumer's virtual shopping cart. Otheraspects of this step are discussed below with respect to correspondingelements in FIG. 3.

At step 208 the secure sells-payment app prompts the consumer to providea method of payment. The service provider may accept payment in the formof major credit cards (e.g., VISA, MasterCard, American Express, etc.),debit cards, pre-paid cards, or gift cards; or by using loyalty pointsor coupons; or through online forms of payment (e.g., PayPal, onlinebank payments). Other aspects of this step arc discussed below withrespect to corresponding elements in FIG. 3.

At step 210 the consumer is given the opportunity to confirm thetransaction before it is completed. The secure self-payment app displaysinformation about the transaction to be completed for review by theconsumer, such as the goods or services to be purchased, the price ofeach, the total price for the transaction, and the proposed method ofpayment. In some embodiments, in connection with step 210 the appprovides the consumer with additional offers related to the proposedtransaction, such as the purchase of warranties or bags. Depending onthe level of security and the method of payment selected, in certainembodiments the app prompts the consumer to enter a personal PIN orpassword to confirm the purchase. In another embodiment, the app promptsthe consumer to enter a card security code for credit card transactions.

At step 212 data relating to the transaction, or “transaction data,” isverified and then transmitted by the secure self-payment app to theservice provider web API for verification. This transaction dataincludes information needed for the service provider and third partiesto process the transaction, such as identifying information for thegoods/services being purchased, the quantity thereof, the consumer'sidentifying information, and information about the method of payment.Relevant portions of the transaction data related specifically to theamount and method of payment are sent by the service provider web API tothe retailer and third-party credit card processing network to processthe financial transaction. Relevant portions of the transaction datarelated to the goods or services being purchased, the quantity thereof,and the method of payment are sent by the service provider web API tothe retailer. Examples of data that may be sent by the service providerweb API to each relevant party as a direct result of the consumer'sinputs into the self-payment app include requests for paymentauthorization to the payment processor, credit card issuer, issuing bankor online wallet; removal of item(s) from store inventory, consumerdetails; and issuance of a receipt to the consumer for later review. Inthese examples, the payment authorization is sent to a third-partypayment processor, an item removal request is sent to the retailer,consumer details are updated and saved in the consumer profile and thenviewed along with the receipt by the consumer once it is generated andsent back to the consumer's device.

At step 214 the consumer receives a unique code or identifying elementto verify the purchase of goods and services. In the preferredembodiment and as described in connection with FIG. 2, this code is a QRcode. In particular, once all transaction items are successfullycompleted, the service provider web API returns a unique, transactionspecific QR code for display on the consumer's mobile device, such as asmart phone. As discussed in additional detail below, in a preferredembodiment the QR code contains embedded therein a token in the form ofa Uniform Resource Location (URL) string that links to informationregarding the purchase of goods and services. As an example, such URLmay take the following general form;https://www.selfpayserviceprovider.com/transactions/34561 where thefirst portion of the address is used to identify the server location,the next portion is used to identify the type of view, and the numericalor other value is used to represent the unique data record for thepurchase.

At step 216, the consumer presents the unique code to the retailer toverify the purchase. Once the service provider web API sends the uniquecode to the consumer, the consumer's device makes the code availableliar capture by the retailer, who can then use the code to verify thepurchase of goods and services. In the preferred embodiment, the appvisually displays the unique code, in this instance a QR code, on theshopper's mobile device so that the shopper may exit the store withconfidence that his or her transaction was successfully completed. Aretail associate scans the displayed QR code with a retailer mobiledevice that has a retailer verification app installed therein, or withanother compatible scanner that allows the retailer to capture a QR codeand view the transaction including items purchased and paymentverification on its scanning device and/or mobile device. In thepreferred embodiment, once the retailer device captures the QR code, theretail device links to a specific dynamically generated data feed basedon the uniform resource location (URL) embedded as a string in the QRcode. This URL is accessed through a domain name server lookup thatconnects the retailer app to a specific location on the service providerweb API. The specific location corresponds to a data record in thedatabase of the specific original purchase sent through the self-paymentapplication. In this context, the terms database and data record includenot only traditional databases and entries therein, but any otherstructure for storing information in an organized fashion and includes,but is not limited to, a collection of log files on a server containedin a folder. The capturing of the QR code and underlying string isperformed by the retailer device 104 through the use of communicationlink 110. Request for record retrieval is performed by communicationlink 114 and then pushed back to the retailer 104 for display on theretailer device by the self-payment service provider 106 using the samelink 114 as a reply. The retailer captures the QR code as a means ofspot checking the transaction. This may be done either in-store,immediately outside the store, or at the point where a consumer may askfor tag removal or bags, if applicable. The place where the retailerdecides to implement its spot check depends on its individual in-storephysical retail flow preferences. Inventory tag removal or desensitizingand bagging is optional but may be offered by some retailers. The optionto verify the consumer's purchase of goods or services through thecapture of the code provided by the service provider web API is acritical option in retailer security of the transaction and is in placeto minimize theft or shrinkage. In the preferred embodiment, the QR codeis used only for verification purposes and not payment. Depending on theretailer's preferences and desired level of theft prevention, theverification process of capturing the code presented on the consumer'smobile device may be employed for all, random or no shoppers asprescribed by specific retailer preferences.

FIG. 3 describes the actions taken by the consumer to complete a sale orreturn while using a secure self-payment application.

The process flow 302, “Registration Flow,” involves the registrationsteps associated with the first-time use of the system by the consumer,including the entry of personal, payment, and/or optional data.According to the embodiment shown in FIG. 3, the registration processflow includes the following steps: download app 304, sign up 306, andenter profile and preferences 308.

In step 304, “Download App,” die service provider makes the self-paymentapplication available for download to the consumer's device. Thedownload may be triggered through a number of different actions taken bythe consumer. The service provider can make the application availablevia any number of known distribution methods, such as an “app store”download, web site link, a QR code that contains a link to a downloadlocation and which may be scanned by a camera on a consumer's mobiledevice, or other known methods for sending the application to theconsumer's device.

At step 306, “Sign Up,” using the functionality provided by theself-payment application the service provider allows the consumer tosign up for the self-payment service. In connection with this step theservice provider may require that the consumer input contactinformation, such as a valid e-mail address for communication andperform an e-mail verification step. The self-payment application mayfurther prompt the consumer to input other personal identification datasuch as name, addresses and phone number, social media information suchas social sharing usernames, payment data such as credit card numbers ore-wallet accounts, verification data such as a unique PIN oridentification code or other data that may or may not fall into thesecategories. Depending on whether this data is sensitive and or hasspecific legal requirements for its collection and storage, the serviceprovider may store this data on its servers while employing varyinglevels of security on a server or with a third-party, or in some caseswithin the app on the consumer's device. The service provider may alsomake the app usable in a limited “browse-only” state if little or norequired information is entered into the app by the consumer.

At step 308, “Enter Profile and Preferences,” the self-paymentapplication provided by the service provider prompts the user toestablish a profile and allows the user to enter in preferencesassociated with his or her use of the self-payment service. Inconnection with the sign up step 306, the service provider requires theconsumer to enter in individual pieces of identifying data to create asecure self-payment account, and for the service provider to create aunique user ID for the consumer. The consumer profile is characterizedby the data entered by the consumer in step 306, and is associated witha unique user ID. Through the functionality provided by self-paymentapplication, the service provider may prompt the consumer to enteradditional data not required in the sign up process or to modify thedata previously entered. Additional data may include additional desiredpayment methods, identification, social media information, informationon family members or other data that may affect the performance orusability of the app and the secure self-payment method. Some of thisinformation is optional for core functions, but all collectedinformation generally has the purpose of being used for customerprofiling, payment, marketing and item suggestion or third-partyfunctions. The app may also allow the consumer to toggle certainsettings, which modify the behavior of the service provider web API orthe secure self-payment application. Preferences may include pushnotifications, opt-in advertising or other custom app behaviors.

The process flow 310, “Push Notification” is an optional process, foundin certain embodiments. The push notification flow involves the processof launching the self-payment app without the need for the consumer tomanually select and launch the app using the operating system (OS) ofthe consumer's device. According to the embodiment shown in FIG. 3, thepush notification process flow 310 includes the following steps:approach or enter participating store 312, and send message thatconsumer is in store 314.

In the approach or enter participating store step 312, the web API isnotified that the consumer's device is near a participating retailer ifthe device is physically near or in the store. The notification may betriggered as the mobile device connects to the store breaches a“Geofence” or otherwise triggers another location service that causesthe web API to send a push notification to the device screen.

At step 314, “Send message that user is in or near store,” the web APIdisplays a message on the consumer's device that notifies the consumerthat he or she is in or near a retailer that supports the secureself-payment system. The message greets the consumer and displaysoptions to launch the app or to acknowledge and dismiss the pushnotification. The specific message text may be determined by acombination of factors such as preference settings, item lookup historyor desired items.

The process flow 316, “In-Store Flow,” describes the actions taken bythe consumer while in-store to complete a secure self-paymenttransaction. According to the embodiment shown in FIG. 3, the in-storeprocess flow includes the following steps: launch app 318, build cart320, and confirm payment 322.

In the launch app step 318, the app is launched so that purchase anditem scanning functions can be performed. This may be done either bycompleting the steps described in 310, by manually selecting andlaunching the app in the mobile device OS, or from within another app orweb browser.

At step 320, “Build Cart,” the secure self-payment app keeps a tally ofthe items that the consumer wishes to purchase in an electronic in-appshopping cart. The shopping cart is built as the consumer scans anidentifying code (such as a barcode or other unique item identifier)with the device camera or otherwise looks up and confirms items that heor she wishes to purchase or view in-app. The web API displaysinformation from a linked database that includes price and may includeinformation such as product description, images, additionalrecommendations or other information that may aid the consumer in makingthe purchase decision. The app may give the consumer an option toconfirm the item for purchase and to either store it in an in-appvirtual shopping cart with other previously entered items or to purchasethe item alone. There may be an option to select a desired quantity ofthe item or to add specific promotional codes. The web API may alsodisplay promotions and suggestions triggered by the customer's use ofthe app. To provide the consumer with meaningful promotions andsuggestions, the secure self-payment system may track and monitor theconsumer's item lookup and purchase history as well as use all dataentered by the customer when setting up or modifying the consumerprofile. If the consumer chooses to add an item to his or her virtualshopping cart and continue shopping, this step repeats until theconsumer has added all the items he or she wishes to purchase. Once thevirtual shopping cart contains all the items that the consumer wishes topurchase, the purchase may be completed as described in subsequentsteps. In addition, the service provider may offer an optional“shipping” function. This shipping function may be used to allowconsumers to add items to their shopping cart in-app and then have themshipped to a physical location instead of taking the items with them ontheir way out of the store. In this case, the web API communicates withthe retailer that the purchase should be shipped to a designatedaddress.

For many reasons, and in particular for reasons related to security andanti-theft concerns, a retailer may create restrictions that areimplemented by the self-payment app or web API that only allow specificitems to be added to the shopping cart or that impose transaction oritem value limits. In some cases, items may be at high risk of runningout of stock, too large, to carry out of the store and may poseliability issues (e.g., a television set), too expensive to purchasewithin the secure self-payment application as deemed by the retailer(e.g., a high-end digital camera), or may carry an inventory tag thatthe retailer wishes to remove or de-activate themselves. Where theretailer has created such restrictions, the consumer is notified of thespecific restriction in-app once the web API retrieves the productinformation from the item database including any associatedrestrictions.

At step 322, “Confirm Payment,” the shopping cart takes the item andprice data and displays a total purchase amount in-app on the consumer'sdevice. The secure self-payment application displays the total purchaseamount and prompts the consumer to select his or her default paymentmethod, or to select another saved payment method, or to create a newpayment method. The secure self-payment application may also give theconsumer options to change quantities, add promotional codes, removeitems or to go back to step 320 to add more items to his or her in-appvirtual cart. The secure self-payment application attempts a purchasethrough the web API and the payment processor once the consumer confirmshis or her intent to attempt to apply his or her selected payment methodto the proposed transaction. In the preferred embodiment, step 322 isonly completed once the consumer confirms the purchase amount in-app andagrees to begin the checkout process.

If the original payment method is declined by the payment processor, theconfirm payment step 322 can be re-attempted by the consumer withanother default, stored, or new payment method. The in-app virtualshopping cart maintains the same items that were added by the consumeruntil a payment method is entered that is accepted by the paymentprocessor, the consumer leaves the store, a lengthy amount of time :haspassed, or the consumer opts to clear the cart. If there are multiplefailed purchase attempts either due to a failed or declined request sentto a payment processor or other fault such as an error with generating aunique verification code, such as a QR code, the secure self-paymentapplication optionally displays a message that directs the consumer to alive retail associate or service desk for additional help. The secureself-payment method optionally also notifies the retailer of a failedpurchase attempt via the retailer mobile device or POS system for theretailer's own fraud prevention measures. Where a consumer ortransaction poses a particularly high security risk, the process may notpermit the confirm payment step 322 to be re-attempted by the consumerfollowing a declined payment method, or a specific number of declinedattempts, as specified by the retailer.

The process flow 324, “In-Store Return Flow” describes the consumerprocess when returning or exchanging an item originally purchasedin-app. According to the embodiment shown in FIG. 3, the in-store returnprocess flow includes the following steps: retrieve receipt 326, presentQR code 328, return or exchange item 330, and refund or exchange honored332.

At step 326, “Retrieve Receipt,” the secure self-payment applicationmakes the receipt available to the consumer for display on his or herdevice. The receipt can be stored and displayed in the self-paymentapplication. In addition, the web API is capable of sending the receiptto third-party apps, such as Apple Passbook, or to an e-mail account,whereupon the receipt can be retrieved and displayed in such third-partyapp or e-mail application. After speaking to a retail associate aboutwishing to initiate a refund, the consumer retrieves the receipt fordisplay to the retailer to provide verification of the originalpurchase. In the preferred embodiment, receipts are stored in a“purchase history” section within the self-payment application. Otherimplementations may be used for storing and retrieving receipts,however, and these other implementations may vary depending on theconfiguration of the secure self-payment application or third-partyapplication. Receipts may be organized by date, retailer, types ofitems, geographical location, payment method and/or other Criteria.

At step 328, “Present QR Code,” through the self-payment application theservice provider makes available for capture a unique token, generallyin the form of a UPI link, that can be used to verify the consumer'spurchase of the goods or service. In the preferred embodiment, theself-payment app displays on each receipt a QR code, which is agraphical representation of the unique token, such as a unique stringcode that represents a URL of dynamically generated web content,corresponding to the database entry containing information regarding thepurchase of goods and services. In another embodiment, the self-paymentapplication makes available the token or URL for capture by the retailerdevice via wireless data connection, such as NPC. In the preferredembodiment, when the QR code is captured by the retailer device, theretail device extracts the embedded URL code and links to the serviceprovider's web server maid can request data across a variety of formats(typically XML, or JSON). The capture of the token, such as the scanningof the unique QR code or transmission of the token via a wireless link,is performed by the retailer device 104 through the use of communicationlink 110. Request for record retrieval is performed by link 114 and thenpushed back to the retailer 104 for display on the retailer device bythe self-payment service provider 106 using the same link 114 as areply. In the case the app is provided by web technologies (for instanceHTML5, CSS, etc.) a web form or page containing information relating tothe purchase such as time and date, items purchased, consumer identityand purchase amount is sent by the web API for display on the retailerdevice. The web view may be accessible as either a web page or as a datafeed. In addition, the web view may require device authorization on theretailer device with one or more authentication factors to ensure datamanagement. Possible authentication factors include pre-login password,login password, encrypted key authorization, Device Registry Checks(stores of authorized manufacturer serial number) and/or biometrics. Inthe preferred embodiment, the verification QR code is visible on allreceipts, but exact placement of the QR code on the receipt may vary.Once the QR code is visible and clearly displayed on the device screen,the consumer may present his or her mobile device to the retailer forcapture or manual entry of the displayed transaction number.

The retailer then captures the unique token, such as the QR code, ormanually enters in a corresponding transaction number either through thefunctionality provided by the secure self-payment retailer verificationapp or compatible retailer POS system and/or custom conversion softwareand hardware. Upon successful verification, the retailer verificationapp or compatible retailer POS system displays an itemized receipt onthe retailer's device. In the preferred embodiment, the retailer followsits specific return or exchange procedures via its mobile device runningthe retailer verification app or POS system. This step 328 requires theretailer to select the items being returned or exchanged through the useof its chosen QR code reading method. The consumer may also be askedwhether he or she would like the transaction refunded to his or heroriginal payment method, store credit or other as per the retailer andpayment method rules.

At step 330, “Return or Exchange Rem,” once the token and correspondingpurchase have been successfully verified and the retailer has performedany necessary steps on its end, the item is returned or exchanged. Aspreviously discussed, in the preferred embodiment the token is providedin the form of a link embedded in a QR code that links to a transactionURL with transaction information. The transaction URL may contain accessrestrictions, for instance those of a specific consumer or retailerdevice. In certain embodiments, a substitution technique enables the QRcode associated with the transaction to access more data under strongersecurity restrictions and different user permissions. For example, thestring https://www.selfpayserviceprovider.com/transactions/34561 couldbe read and replaced programmatically byhttps://www.selfpayserviceprovider.com/exchanges/34561. This accesswould have stronger access restrictions: not accessible by consumerdevice and only accessible for retail devices and accounts authorized toprocess exchanges. Because of the exchange needs, the data attached tothis information on the service provider server could include theoriginal method of payment and a payment transaction id token to be sentto the payment processor to handle the refund or exchange. The QR-codedreceipt and surrounding architecture is used as part of the secureself-payment method so that the return can be made in compliance withfinancial laws and retailer specific policies without needing theinformation necessary to do so to be present on either the consumerdevice or the retailer device/POS. If the transaction is an equal-valueexchange, a monetary transaction is not performed. After the retailersuccessfully performs a refund or exchange, a new, modified receipt iscreated by the web API and this updated receipt and transaction isstored on the server. The next time the consumer accesses his or herpurchase receipts, the self-payment application downloads all updatedreceipts from the service provider server, including a new QR code, withthe new string pointing to the revised receipt. This enables both theretailer and the consumer to see the new information while enabling theservice provider to have full records of the transaction history asseparate transactions stored in the consumer's profile with the serviceprovider and may be viewed by the consumer in-app. In a non-preferredembodiment, the QR code remains the same, but the information beinglinked to by the QR code reflects the changes to the transaction as aresult of the return or exchange. These changes to the QR code areperformed by modifying the existing entries in the data record toinclude additional information regarding the change, such as to indicatethe return, and generate an updated receipt for that return, as opposedto creating a new transaction for the return and a receipt for thattransaction. In this embodiment, the updated receipt may also be storedby the retailer and such receipt data may be modified in such a way asto reflect the details comprising the modified transaction.

At step 332, “Refund or Exchange Honored,” the secure self-paymentapplication makes available an updated electronic receipt to theconsumer. The consumer is then able to verify electronically through theuse of the secure self-payment application that his or her purchase ofthe returned item has been marked as returned or exchanged. In certainembodiments, the retailer gives the consumer a paper record of thereturn, or the retailer keeps a paper record for itself.

Process flow 334, “Out of Store,” is an optional process found incertain embodiments. This process flow describes a feature provided bythe secure self-payment system that some retailers may implement toallow consumers to pre-purchase or pre-select items or services beforearriving at a physical retail location. The out of store process flowincludes the following steps: add items or services to cart 336,approach or enter participating store 338, pick up items 340, andpresent QR coded receipt 342.

Step 336, “Add Items to Cart,” is similar to the build cart step 320 ofthe in-store process flow. The main difference between steps 336 and 320is that in step 336 of the out of store process flow the secureself-payment application is opened while the consumer and device are notphysically in the retail store. The service provider makes it possibleto add desired items to the in-app shopping cart through the use of thesame item identification techniques as described in step 320.

As items are added into the shopping cart, the secure self-paymentapplication sends out a request to the retailer network to confirm thatthe retailer carries the item and that it is stock.

As described in greater detail herein, the consumer's mobile device andself-payment application may be equipped with location servicefunctionality, which permit the device and application to determine theconsumer's location and whether or not the consumer is located within ornear a store. When such location services are enabled, the secureself-payment application may display a separate “out of store” shoppingcart on the retailer's page or section in the application when theconsumer is not in the store. This out of store functionality islaunched through a designated section within the secure self-paymentapplication.

In the preferred embodiment, the retailer allows the secure self-paymentapplication to complete the payment using the process described in 322and to generate the QR code before the consumer physically arrives atthe retail store. In a preferred embodiment, the self-paymentapplication stores the QR-coded receipt in a separate categorydesignated for the pick-up of goods and services. This QR code stores aunique string URL token resembling:https://www.selfpaymentprovider.com/pick-up/23451 where the itemsavailable for pickup would be listed. Upon a successful pick-up of allitems, a receipt of the normal transaction variety is generated andstored as an ordinary receipt, and the pick-up receipt is erased fromthe consumer system. In the event of a partial pick-up, a revisedpick-up receipt is generated for the outstanding items, and a partialreceipt is generated for the items picked up. This process involvescreating a data entry in the corresponding record indicating which itemshave been picked up by the consumer, and which items remain for pickup.Upon picking up the remainder of the items, a second partial receipt isissued. Alternatively, upon picking up the reminder of the items thereceipts are merged.

Step 338, “Approach or Enter Participating Store,” is similar to step312 in the push notification process flow, in that the serviceprovider's web API is notified that the consumer is in or near theretail store and that the consumer may launch the app. In this case, thedisplayed message is used to notify the consumer that he or she hasitems in-store that have already been purchased and which are waiting ona pick-up.

At step 340, “Pick Up Items,” once the consumer is in the store, he orshe may locate the desired items either in-aisle or at another retailerspecified location. The consumer may take the items which were paid forin 336 as described in 322 and begin to make his or her way out of thephysical store.

At step 342, “Present QR Code,” per the retailer's loss preventioninitiatives, the consumer may be asked to display the QR code generatedby the secure self-payment application on his or her way out. The QRcode is then read by the retailer's verification app that generates apurchase lookup query for the service provider's web API. Although thisstep is described in connection with the preferred embodiment whereinthe token is in the form of a URL link embedded in a QR code that isdisplayed to the retailer for capture via scanning, it would beappreciated that this step may take other forms where the unique tokenis presented via wireless transmission, such as through NPCcommunications. For example, the consumer may place the consumer devicein close proximity to the retailer's electronic device operating theverification app (or other POS device having similar functionality),whereupon the consumer device and electronic device establish a wirelesscommunication link that permits the consumer device to transmit theunique token to the retailer's electronic device.

FIGS. 4A and 4B are a process flow chart showing the technical steps inthe secure self-payment system according to an embodiment of theinvention. This figure describes a process that results in a transactiontogether with the retailer verification process. This figure mainlydescribes the behavior and processes of the web API, although certainsteps or portions thereof can be undertaken by the consumer in-app viathe self-payment app on the consumer's mobile device. In this sectionall references to a web API or API, unless specified as third-party orother, refer to the service provider's self-payment web API. Asdiscussed below, the self-payment web API may take the form of one ormore servers with programming that enable them to perform thefunctionality described herein. The process described in FIGS. 4A and 4Bcan be varied based on a variety of factors. For example caching may beoptional depending on implementation details. Furthermore, this processdescription is designed from the perspective of a service provider whois not a payment provider, and assumes that the service provider storestokens that are linked to credit card data on a payment provider orpayment service network rather than directly storing credit card data.Those with relevant experience will recognize that these and other minorvariations can be made to the process, including the addition,exclusion, and variation of certain steps, while still remaining withinthe scope the secure self-payment systems and method described herein.

At step 402 the consumer through the functionality provided by theself-payment app on the consumer's device sends a purchase request byadding items to the virtual shopping cart, making selections thatindicate he -or she wishes to confirm and pay for the specific selecteditems including selecting a specific and personal method of payment. Theconsumer has thus declared his or her intent to purchase the items inthe in-app shopping cart as described in 322.

At step 404 the web All caches the purchase request sent by theconsumer's mobile device. In this step the shopping cart data such asitems, prices, quantities and final total is cached by the web API foruse by the secure self-payment system.

At step 406 the web APT sends the payment request to the secureself-payment application running on the consumer's mobile device. Apayment request is sent to the consumer's mobile device from the web APIfor payment confirmation. The request uses the cached data from step 404but may also add in additional data such as tax policies or otherdiscounts that were not properly applied at the previous stages. In thepreferred embodiment this request uses JSON and various well knownencryption technologies including HTTPS while ensuring that the securekey matches the service provider's secure key, is signed by a validsigning authority, and is current. In the preferred embodiment, theconsumer can initiate this automated process by hitting a purchasebutton.

At step 408 the web API, or alternatively the self-payment applicationrunning on the consumer's mobile device, checks to determine if theconsumer would like to use a saved or cached credit card or paymentmethod, and determines whether or not the method selected by theconsumer is valid. Two possible outcomes of the check at step 408 are“Yes” and “No”. “Yes”, step 410, is a result of a stored and validpayment method being found and selected by the consumer in-app as his orher method of payment for the current purchase. “No”, step 412, is aresult of either an invalid payment method being found and selectedin-app by the consumer or a result of no payment information being foundor entered in by the consumer at any point. Throughout steps 408, 410and 412, “valid” and “invalid” payment methods are from the perspectiveof the service provider. Note that a payment processor may later rejecta “valid” payment method. For example, a consumer may have selected a“valid” payment method but later the payment processor may reject it dueto unavailable credit.

If the result of the check at step 408 is “YES” then the system proceedsto step 410 in which the consumer may enter payment or identityverification. If the check at step 408 comes back with a previouslysaved and valid payment method, the secure self-payment applicationprompts the consumer to verify his or her identity or ownership of themethod through the entry of a unique identifier. This unique identifiermay depend on the method of payment employed by the consumer, and may bea credit card's verification value, a custom secure self-payment methodor other payment method PIN, or a third-party security login orverification such as Verified by Visa.

If the result of the check at step 408 is “NO” then the system proceedsto step 412 in which the consumer enters payment data via the secureself-payment application running on the consumer's mobile or via athird-party API. If the check at step 408 comes back with no previouslyused or stored payment method, the self-payment application prompts theconsumer to enter in a new payment method along with all relevantverification data such as name, address, card verification value,birthday or other checks that may be used to prove ownership of thepayment method. Likewise, a similar full-entry interface may bepresented to the consumer if the check at 408 returned with a previouslysaved, but currently expired or invalid, payment method. The secureself-payment application may allow the consumer to enter a paymentmethod either through direct manual entry through the application, orthrough the use of a third-party information capture API. In thepreferred embodiment both of these methods are implemented and theconsumer is offered a choice. Example third-party APIs may include imagerecognition via the camera on the mobile device to verify a physicalpayment card or ID, or other well-known methods of payment entry notrelating to manual in-app data entry. Once the secure self-paymentapplication receives payment method information, the same shortenedverification steps discussed in step 410 may apply in order to verifythe payment method.

At step 414 the self-payment app on the consumer's mobile device sendsthe payment request data using HTTPS to the retailer's web API. Thepayment data and verification values are sent securely over HTTPS to theweb API for further processing.

At step 416 the web API receives the payment data and verificationvalues and passes this information forward to a payment processor. Thereare four case scenarios in which the payment data is sent to a paymentprocessor: (i) the secure self-payment system caches credit cards; (ii)the retailer's POS Caches credit cards; (iii) the retailer's POS passespayment to a third-party; and (iv) the secure self-payment system passespayment to a third-party. This step involves the passing on of paymentdata for processing. The method in which the payment data is processedmay be performed using any number of well known techniques and may varybased on retailer type, agreements, payment method, third-party used ora number of different factors.

At step 418 the payment provider processes the transaction or sends backa warning. This step is the response to the payment request sent by thesecure self-payment system to the payment processor. The three possibleoutcomes are: (i) transaction approved; (ii) transaction declined; and(iii) a request for payment info re-entry. Re-entry may be a result ofan expired payment method, incorrect data entry or other factors asdetermined by the payment processor.

If the transaction is approved, the system proceeds to step 420 wherethe web API processes the previously cached purchase data together withthe payment approval code and saves it to the service provider databaseas an approved purchase. This database could be a separate database on aseparate server the service provider uses for payments, a database onthe same server as the inventory database, a different table in the samedatabase as the inventory database, or an extension of the same table.In this context, the terms database and data record include not onlytraditional databases and entries therein, but any other structure forstoring information in an organized fashion and includes, but is notlimited to, a collection of log files on a server contained in a folder.The approved purchase transaction may have additional data elements (or“data entries”) added to the record which does not include the sensitivepayment data but can include purchase data such as: items purchased,total purchase amount, payment type, location and time of purchase,consumer ID, payment ID number, or other non-sensitive informationrelating to the purchase. This data is stored for later use for purchaseverification, returns or exchanges, or marketing initiativescorresponding to a successful transaction. The payment query returns tothe service provider web API and the consumer's payment method ischarged or debited. At this point, sensitive data has been processed andis not stored with the service provider's API.

At step 422, according to the preferred embodiment, a QR coded receiptis generated by the web API. The generation process for the QR codeoccurs as follows. A unique token is generated that is associated withthe approved purchase transaction record. The token can be associatedwith the approved purchase transaction record in a number of ways. Forexample, the token may be associated with the approved purchasetransaction record by virtue of a lookup table. Alternatively, the tokenmay be a URL link (or portion thereof) that links to the approvedpurchase transaction record. The token is transformed into a unique QRcode through the use of a QR code generator, which generally takes theform of a software function. This QR code generator may be a modulewithin the web API or may be hosted by a third party on a third partyserver in communication with the web API via a network. The QR codegenerator receives as an input the token and returns a QR code with thetoken embedded therein. In this manner, the QR code is a representationof a web or network address associated with a page and/or data feedconnected programmatically to the database entry corresponding to theconsumer's purchase. For example, if the transaction ID for a purchasein the database has the unique identifier 34152 then an example QR codewould be an encoding of the stringhttps://www.selfpaymentserviceprovider.com/transactions/34152. Theretailer devices can determine which web or network location to accessby capturing this string from the consumer's device—through eitherscanning a QR-coded receipt or other capture techniques such as NFC.Data that may be represented by the web page or other method of dataexchange can be loaded using the link provided in the QR code togetherwith information embedded in the retailer application, through thepreviously described web-view methodology.

At step 424 the token is sent to the consumer's mobile device forstorage. In the preferred embodiment, the token is sent in the form of aQR code. The QR code generated in step 422 is sent by the web API to theconsumer's mobile device for display and storage.

At step 426 a spot check may he performed by the retailer. This stepreferences the act of the retailer verifying the consumer's purchase. Inthe preferred embodiment, for retail spot checks the secure self-paymentapplication displays the QR code generated in step 422 upon request, bythe consumer, if asked by the retailer to provide proof of purchase. Inan alternative embodiment, the consumer's mobile device is brought intoproximity of the retailer's device so that the token associated with apurchase transaction can be wirelessly transmitted to the retailer'sdevice for verification purposes. The frequency of spot checks is leftat the retailer's discretion. This spot check maybe performed at random,always, sometimes, or not at all. In all purchase cases performed by theself-payment application, the QR code can be provided as a method ofpurchase verification. This QR code may be sent by the web API fordisplay either in the secure self-payment application, third-party appsor other methods of displaying the QR code. There are two outcomes tothis step: yes or no, corresponding to whether a spot check isperformed, or is not performed, respectively.

If the outcome of step 426 is a “yes” (corresponding to a spot checkbeing performed) then at step 428 a cheek for a purchase correspondingto the token or displayed QR code is performed. Through the use of theretailer verification app or compatible hardware or software running theservice provider's web API such as a POS system, the retailer capturesthe QR code that is displayed on the consumer's device. Once theretailer's device captures the QR code, it sends a request to theservice provider web API to determine whether the QR code is valid. Ifthe link embedded in the QR code points to a service provider databaseentry representing a valid purchase, the web API interprets the QR codeas referring to a valid purchase receipt (i.e., having a “match”) andmay further return the associated purchase information retrieved fromthe data record in the service provider database. There are two possibleoutcomes for step 428: match or no match, corresponding to whether ornot there is a match between the data record linked by the QR code and adatabase entry in the retailer's and/or service provider's database.

If a match is confirmed, then at step 430 the system operates toindicate on the retailer's device that there is a match between the datarecord linked by the QR code and a database entry in the retailer'sand/or service provider's database (i.e., a “match’) such as bydisplaying the details of the consumer's transaction on the retailer'sdevice operating the verification app. Step 430 follows if the QR codematch request from step 428 finds a transaction in the retailer's and/orservice provider's database that is linked to the displayed QR code. Theretailer's device optionally displays the items purchased, consumer'sname, total purchase, amount, time and place of purchase or other datathat may be used to then verify the purchase visually or through othermethods. A positive “match” occurs when the QR code displayed by theconsumer mobile device is confirmed to point to a database entry thatexists in the web API and references one specific transaction conductedby a specific consumer at that retailer. The system determines that a“match” is made if the web API retrieves purchase information from thedata record link stored in the QR code. If a match occurs, the web APIwill then send the linked purchase receipt containing the purchaseinformation stored in a database in 420 to the retailer device overHTTPS, SSH, or other encrypted exchange technology which is thendisplayed on a visual interface through the retailer verification app.The information that is part of a match reply includes data such as thepurchase time, the customer profile photo, and all the purchased itemson the consumer's receipt so that the retailer can ensure the validuse-case. It can also have geo-tagged information about whether theconsumer has left the store since purchase, and/or the number of timesthe receipt has been scanned.

If no matching QR code is found, then at step 432, the system operatesto indicate that there are no results (i.e., “no match”) or no purchasetransactions referenced by the consumer displayed QR code so that onretailer device, a message will appear indicating that no matchingtransaction was found. Step 432 follows if the QR code match requestfrom step 428 has not found a transaction in the retailer's and/orservice provider's database that is linked to the displayed QR code.This may be a result of a mis-scan, lack of network connectivity, acracked screen or drained battery on the consumer's mobile device,failure to meet security permissions such as an unregistered retailerdevice or a number of other factors. A “No Match” indication is awarning that purchase information was not successfully retrieved andsent to the retailer's device. This warning can be further divided intoa number of specific error messages with recommended steps to correctfor ease of use. The warning message may be customized in a variety ofways depending on the implementation details, the technology partners,the retailer preferences, the qualifications and training of the lossprevention associate and other factors. For example, automated threatrisk software could flag the fail as a high risk transaction if itdetects a clear attempt to spoof a receipt, and a low risk transactionin the case of identifying a broken or invalid link on a server with thecorrect secure keys or if the retailer device loses its interneconnection.

Step 434 follows a “no match” result at step 432, and involves theretailer applying its own fraud prevention processes for this use case.If the secure self-payment method spot-check fails, the retailer maychoose to use a number of other fraud prevention methods based on thatinformation. These fraud prevention methods may be whichever methods)the retailer currently employs or wishes to employ.

Step 436 follows the payment processor query at step 418 resulting in afailure to process the payment information sent from the self-paymentapp at step 418, and serves to notify the consumer of the failure. Ifthe result of 418 is a failure, the web API notifies the consumer of atransaction decline. The web API may further prompt the consumer tore-enter some information in the secure self-payment application and toretry processing of the payment information.

At step 438 the web API generates and caches failure data for riskanalysis. The failure data may include information corresponding to thereason that the payment processor indicated a failure to process thepayment information it received this may be represented as an errorcode. The failure data may be used for purposes relating to security andpayment integrity or for other risk related processes and activities.

At step 440 the service provider evaluates risk based on the failuredata. This step includes the service provider's internal analysis andprocesses relating to risk levels and transactions. Processes mayinclude behaviours such as closing or suspending a consumer's account ornotifying payment processors or issuing banks of certain behaviours.This behaviour may be driven by many factors and is flexible and dynamicdepending on the needs of the retailer, self-payment service provider,the payment and technology partners, and the consumer. It may be put inplace to minimize fraud while avoiding conflict with the consumer.

At step 442 the secure self-payment method transaction concludes. Thisstep is the result of a completed in-app transaction. The transactionmay be one where a spot check is or is not performed by the retailer.This step may also be a result of a payment method being declined or theconsumer aborting the purchase due to the inability to verify certaininformation with the payment processor.

FIG. 4C shows the steps in the self-payment transaction according toanother embodiment of the invention.

FIG. 5A describes the general relationships and connectivity withrespect to the data shared between the various devices and entities usedin the self-payment systems and methods described herein. Theconnections between these entities can occur by some combination ofconnections to databases on the same network, direct id links betweentables in the same databases, network connections to different databasesby techniques such as polling or POST requests and connections using avariety of addressing methods for security to databases on a differentvirtualized server within the same physical server.

In the preferred embodiment, the data shared between the devices andentities is stored in a combination of the following: core datainstances on to iOS devices; postgreSQL instances on one or morevirtualized servers on one or more physical servers as part of a cloudcomputing solution; a retailer's preferred database technology on anetwork with restricted or severely limited outside access. In otherembodiments, caching, text logs, or other non-database storage methodsmay be used. In the preferred embodiment, the data shared between thedevices and entities is such that a retail associate has no access toconsumer data without the consumer present, analytics data is madeanonymous to protect user privacy, and consumers are able to modifyprofile preferences to set restrictions on the uses of their data.

Consumer profile data 502 includes profiles that are built out ofpreferences and collected consumer information and transaction history.Consumer profile data 502 is used as a component in the process oftailoring the secure self-payment application to the needs of theconsumer and is also a database in which the consumer's settings andpreferences are stored. In the preferred embodiment, this data is usedby the service provider as a part of the information required tosuccessfully craft an offer or item suggestion. In another embodiment,consumer profile data 502 is used as a means of accessing contactinformation to send the consumer service provider messages. The consumerprofile data 502 may also include a consumer transaction log. Thetransaction log is the historical record of all individual interactionssuch as item or QR-coded receipt captures, sales, returns or exchanges.This transaction log, like the consumer settings and preferences, may beused for purposes of analyzing consumer browsing and buying behaviour aswell as for generating consumer item suggestions and offers to bedelivered by the secure self-payment application.

In other embodiments, data referenced in consumer profile data 502 isshared with third parties so that the third party may function properly.An example would be a method of exporting transaction data into anaccounting or budgeting suite.

Examples of data included in the consumer profile data 502 include theconsumer's name, email address, other contact information such asaddress, age, gender, social media account info and a transaction log.In other embodiments, the consumer profile may contain appointmenthistories, social interactions, and consumer/staff interactions. Allsuch data can be carefully collected and managed via consumerpreferences, retailer preferences, laws, industry bestpractices, and avariety of other factors.

The data stored in the consumer profiled data 502 is shared with itemdata descriptors 506 for purposes relating to the lookup of itemdescriptions, images or other details relating to an item being browsedin-app. A consumer's access to item data descriptors 506 may also bestored in the form of consumer browsing history in consumer profile data502.

Consumer profile data 502, or portions thereof are shared with aretailer's local store staff 508 when the consumer would likeinformation on specific store staff and may also be used to storespecific consumer-staff relationships/ratings for item or offerrecommendation or other marketing purposes. The contact history itselfmay also be used in a variety of ways in staff management or HR for theretailer. In the preferred embodiment, this contact history data isstored on the service provider's server. In a nova-preferred embodimentthe contact history data is stored in the retailer server, or acrossmultiple locations with some duplication.

Consumer profile data 502 is shared with promotions data 512 forpurposes relating to promotions, consumer analytics and demand planning.For example, a promotion may be crafted based on the data contained inconsumer profile data 502 which may or may not be unique to theindividual consumer. This connection uses data in consumer profile data502 relating to the consumer's demographics, browsing and purchasehistory.

Data 502 is shared with credit card processing sites 514 to look upconsumer information that is stored by the payment processor whenrequired per security practices. This may be a required step tocompleting payment within the secure self-payment application. Suchlookups may be governed by laws, standards bodies, and other factors anddetails of these connections may vary in accordance with industry bestpractices.

Data 502 is shared with the QR code generator 516 whenever averification QR code is generated and the consumer must display it aspart of the spot check process. In the preferred embodiment, the QRcodes can he generated dynamically and no storage needs exist. In anon-preferred embodiment, the consumer is linked to the serviceprovider's QR code storage for QR code retrieval.

Data 502 is shared with social media sites 518 when a consumer needsaccess to his or her social media account(s) or would like to make asocial media post. This data may be stored or analyzed by the serviceprovider and accessed for purposes relating to item suggestions throughthe secure self-payment application or the social media account. Socialnetwork logins may be stored separately from the consumer sharinghistory, which may be connected to a service provider user account byanonymous id or other method. This would enable a higher security on anylogin and password data for social networks than is typically used bythe social networks themselves.

Store inventory 504 includes data representing the goods and servicesavailable for sale by a retailer.

Store inventory 504 is used as a basic method of item lookup. As theconsumer scans an item identified within the secure self-paymentapplication, 504 is displayed as a means of identifying the item. In thepreferred embodiment, this data is accessed from a copy of the POSprovider's records stored in the server architecture and updated throughthe polling technique described in FIG. 1A.

An optional use of this data is to determine whether an item is instock. The secure self-payment application may be able to dynamicallydisplay an available item count as stored in 504.

An example of this type of data is the item name, UPC and in-storecount. The store inventory 504 can be stored locally or accessed by theservice provider web API.

Each item in the store inventory 504 has its own associated item datadescription 506, as well as other related item lookup data, 504 and 506are closely related as each inventory item and will have its owndescription or other lookup data such as brand name, images, orcategory. The detail of this data connection is subject to the detailsof the POS system, the retailer implementation, industry best practicesand a broad spectrum of other factors. In the preferred embodiment thedata will be mapped to a standard representation on the serviceprovider's network, with the mapping occurring through each pollingconnection.

Store inventory 504 may be linked to promotions data 512 for purposesrelating to tracking promotion usage rates for specific, items and forpromotion adjustment purposes if an item receives or loses stock, or forother purposes whenever items reflected in the inventory data 504 havean associated promotion reflected in promotions data 512.

Item data descriptors 506 are database entries for information requestswhen regarding a specific item. The purpose of the information is tofurther elaborate on the item in question and referred to by the data in504. These descriptors are connected to a transaction for reviewingpurchased items and for user lookups histories. Item data descriptors506 may be a database stored with the retailer on its POS system or anexternal third party database.

Examples of the type of information contained in 506 include brand name,images, written description, item category or other information that isnot specifically 504.

The local store staff 508 contains information about the retailer'sstore staff that may be located within the physical store that theconsumer is in or is browsing.

A purpose of 508 is to let the consumer view available store associatesand to make contact with an associate through the associate's mobiledevice. Local store staff 508 is an optional data set and not requiredfor core functionality.

Data contained in 508 may include the store associate's name, contactinformation and scheduled hours.

Transaction data 510 includes information regarding a completed purchasethis data is connected to all other data described in FIG. 5A. Socialmedia websites 518 may only access this data if specifically requestedby 518 as a result of a user action.

Transaction data 510 is the data from consumers' purchases and is usedin connection with most other data points. A purpose of the transactiondata is to display specific information relating to the purchase on theconsumer receipt visible in the secure self-payment application. Partsof this data such as time of transaction, item purchased, payment methodand retailer may also be used when crafting offers catered to theindividual consumer.

Examples of information relating to transaction data include the itempurchased, item pricing information, time of purchase, location ofpurchase, quantity of items purchased, the name of the retail associatewho helped with item selection (if applicable), discounts received,payment method and the verification QR code associated with the purchasetransaction.

The transaction data 510 consists only of the lower security pieces of atransaction. Information such as payment hashes and tokens, moredetailed credit card information, purchase identifiers, and anyinformation requiring a more fully secure solution is hosted separatelyin accordance with industry best practices, retailer preferences and avariety of factors.

Transaction data 510 is used with customer profile data 502 when theconsumer performs any action relating to a past or present transaction.This is necessary as part of the data in 502 directly relates tocompleted transactions. The service provider may store consumertransaction history within the consumer profile in order to make item orpromotion recommendations. Such information may exist in a broad varietyof implementation factors.

Transaction data 510 is used with store inventory 504 to adjustinventory amounts for sales, returns or exchanges. This is a step takenas a transaction is completed so that the retailer may adjust itsinventory item counts. Connection may be implemented in a variety ofways depending on data access factors, including through third-party POSintegrators, POS API access, or direct connections.

Transaction data 510 is used with item data descriptors 506 to displayitem description data when paired with a transaction. The consumer'sreceipt may display an image of the item or other data not relating toexact item name and item count purchased. Implementation details varydepending upon POS preferences, retailer preferences, any relevantAPI's, SDK's and custom software factors, as well as other factors.

Transaction data 510 may be used in connection with the local storestaff data 508 so that individual store associate's transactions aretracked for commission or other purposes and to link a transaction to astore associate for the consumer's records or other purposes.Implementation details vary depending upon POS preferences, retailerpreferences, any relevant API's, SDK's and custom software factors, aswell as other factors.

Transaction data 510 is closely connected to promotions data 512 as manydetails in the transaction data trigger the behavior of promotions andoffers. Transaction data also has a direct effect on customer analyticswhich may be shared with the retailer. A practical example of this datais to make a specific promotion usable one time only. Once thetransaction is completed, the specific offered promotion may not beaccessed again by the individual consumer.

Transaction data 510 is closely connected to payment and credit cardprocessing sites 514 for reporting and authorization purposes.Transaction data is sent directly to the credit card processor forauthorization. The amount of the transaction as well as other detailssuch as retailer name may be used for display on the consumer's monthlycredit card bill. Purchase processing results are stored withtransaction data.

Transaction data 510 is closely connected to QR code generator 516 aseach transaction is represented by a QR code that is used for in-storeverification. The QR code generation is a product of a successfullycompleted transaction.

Promotions data 512 includes information related to promotions, demandplanning, customer analytics and financial systems.

A purpose of 512 is to keep track of all items offered and sold during apromotion. The secure self-payment system uses this data for manypurposes including inventory balancing, offer crafting, consumer segmentcharacterization, employee training and for other analytics purposes.The service provider may make use of this real time collected data forits promotional initiatives, marketing, advertising, sales and otherbusiness functions in accordance with retailer and consumer agreements.

Examples of data in 512 include consumer real time browsing and shoppinghistory, service provider promotions, and retailer-specific promotions.In addition, 512 organizes and stores data in such a way that it may beanalyzed for dynamic offer crafting. A simple example of this data beingused to craft a suggestion would be a consumer's scan history, but nopurchase, of 11 shirts over 2 days. It is known that the consumer hasscanned 11 shirts but because no purchase was made, the secureself-payment system may recommend a shirt of a different style or lowerprice.

Payment and Credit card processing sites 514 refers to payment andcredit card processing data. A hash is connected to customer andtransaction. As each consumer has payment methods saved in-app andunique purchases, the hash must be connected to both.

The purpose of this data is to verify a transaction as legitimate. Inthe preferred embodiment, such data will be hosted in accordance withindustry best practices. The data includes the consumer's name, address,credit history and other data most often used by the payment processorsas a method of purchase verification.

QR code generator 516 is the QR code connected to a transaction andindividual consumer history. 516 is used to represent a transaction. TheQR code is created to be used as a method of accessing a web form in-appor data for generating a custom receipt.

The purpose of 516 is to create a representation of a transaction thatis used for purchase verification purposes. In the preferred embodiment,QR codes do not store purchase data; they are rather a method ofaccessing the corresponding data. As described herein, in the preferredembodiment the QR code contains embedded therein a token that can beused to verify the purchase of goods and services.

Social media websites 518 includes data related to social optionsconnected to customer history such as scanned or purchased items andshared promotions.

The data stored in 518 may include the consumer's social media friendslist, status updates, shared images or other information stored as perthe individual social media provider agreement. This data is accessedthrough the social media login credentials which may be stored in 502.This is intended to represent the data relationships for social media,which can be a history of what the customer shared to which networks fordata analytics, or a variety of other factors.

Social media websites 518 may access customer profile data 502 when theconsumer wishes to login to his or her social media account while usingthe secure self-payment application. In this case, the secureself-payment application may use the login credentials stored in 502.

Social media websites 518 may access item data descriptors 506 when theconsumer wishes to post pre-determined item information to a socialnetwork and would like to access item descriptions or information.

Social media websites 518 may access transaction data 510 when theconsumer would like access to a previous purchase for posting to socialnetworks. This allows the consumer to post information such as totalcost, place of purchase, or other information relating to a completedpurchase on his or her social media account.

FIG. 5B describes the general relationships and connectivity accordingto another embodiment of the secure self-payment application.

FIG. 6 is a diagram illustrating the devices that may be used inconnection with the self-payment system and method described herein. Thenature of communications between the devices may be further explained byFIG. 1 and FIG. 1A. Descriptions of each of the devices are providedbelow.

Consumer Mobile Device

The consumer mobile device 602 is a small, typically hand-held devicethat a user can take with them from location to location as he or shemoves around during his or her daily activities. Specific examples of aconsumer mobile device include the Apple iPhone, Apple iPod Touch, AppleiPad, Samsung Galaxy, or other well-known portable devices. Thesedevices are modified to include software in the form of an applicationor “app” that provides the devices with the functionality necessary tocarry out the self-payment systems and methods described herein.

Generally, the consumer mobile device runs an operating system (OS) andcan run apps that the user installs through a device app store. Thedevice typically uses some sort of means of inputting information intothe device such as a touch screen or tactile keyboard. Other typicalcomponents include a visual display, camera, location sensing componentand internet connection component. These other components are furtherexplained with reference to consumer mobile device 900, as shown in FIG.9. A mobile device is generally a phone, portable web browser orpersonal digital assistant used to keep track of schedules and dailytasks. In the preferred embodiment, this device contains hardware andsoftware which provides functionality for: providing an Internetconnection to the web API; providing a visual display for a graphic userinterface to interact with the consumer and to display a QR-codedreceipt; providing one or more methods of interaction with thefunctionality provided in the third party provider offering; providing acamera for barcode scanning; providing a camera fur recognition ofcredit and debit cards; and providing a unique device identifier forauthentication reasons. In other embodiments consumer mobile device 602contains hardware and software for: providing a local wirelessconnection to the service provider API; providing a visual, audio,Near-Field Communications or other media channel for transferring aunique token, receipt request, and receipt information.

The purpose of the consumer mobile device for tasks relating to thesecure self-payment method is to allow the consumer to interact with theservice provider's web API and secure self-payment application. Theconsumer mobile device acts as an input method so that information suchas item identification, and personal data and payment data may beentered in-app by the consumer. Likewise, the mobile device screen isused by the secure self-paymentapplication to display the verificationQR code so that it may be captured by the companion retailerverification app. The app receives the inputs and then can connect tothe web API to perform the function desired by the consumer and displaythe proper communications and replies to the consumer on the devicescreen. The mobile device is the physical access point used by theconsumer for access to functions performed in-app and by the web API.

Specific examples of interactions performed through the use of theconsumer mobile device 602 include downloading the self-payment app 304;inputting information related to the sign up process 306; inputtingprofile and preference 308; launching the secure self-paymentapplication 318; building of a shopping cart 320 and 336; enteringpayment information for goods and services 322; receipt storage andlookup 326; QR code display 110 and 328 and 426; token storage andwireless transfer; as well as location-sensitive actions listed in 310.Some of these interactions are not exclusive to the consumer mobiledevice and may also be performed by the fixed consumer device 612.

The consumer mobile device interacts with the other devices through atwo-way likely wireless connection to 608 for purposes likely relatingto payment, item lookup, social media tasks or other features which maynot be performed directly by the service provider or are enhancedthrough the use of a third party service, a two-way likely wirelessconnection to 604 for purposes relating to the retrieval of consumeraccount information, promotions and service provider to consumercommunications, and real world physical interaction with 610, involvingthe use of the consumer's secure self-payment application and mobiledevice screen, and the retailer verification app and electronic devicecamera or other scanning or image capturing mechanism for the purposesof verifying a consumer's purchase.

Service Provider Network

The service provider network 604 is operated on a server or combinationof computers and peripherals that is used to share information betweenparties in the secure self-payment system.

A function of the service provider network is to control access andpermissions to specific information as needed by each party. This can beaccomplished in part by hosting copies that can be accessed via thepolling technique discussed above in connection with FIG. 1A. Thispolling technique is the preferred embodiment of communications betweenthe retailer network and the service provider network. This pollingimplementation could use a 12-factor handshake where each side verifiesthe other's signed SSL Certificate. The network 604 may route trafficand allow or deny permission based on a variety of criteria such asaccessing device type or IP, account type (consumer, retailer or thirdparty), security clearance such as first-time user, regular user orthird party, or other criteria that may be used to describe theaccessing device for purposes relating to access permission. The serviceprovider network 604 also hosts the web API. One embodiment wouldrequire a three-factor authentication where the first factor is a checkof the device IMEI (a unique hardware identifier) matching the deviceconnecting to the network to the user account, and the second would be auser token exchanged entirely over HTTPS to verify the user account fora user mobile device connection to the Service Provider network, and thethird would be a user PIN handled on the local device. Devices failingthe three-factor authentication could be denied access to certainfunctionalities until the user registers the device: in the event thatthe user account token fails, all functionality exceptregistering/changing users could be disabled.

Specific examples of interactions performed by the service providernetwork 604 include communicating query replies to the consumer mobiledevice 602 regarding consumer account information, promotions, QR, codeverification reply or other service provider to consumer communicationsas outlined and explained in FIG. 8. Other interactions involving theservice provider network involve communications with the retailernetwork 606 for purposes of item pricing or consumer information lookupto he pushed to the consumer mobile device 602; a link to the retailerelectronic device 610 used to receive an interpretation of the capturedQR code in order to push the appropriate reply to 602 consumer mobiledevice and retailer electronic device 610; and a link to a non-mobileconsumer device 612 used for some of the same communications as with theconsumer mobile device 602. The non-mobile consumer device 612 isexplained further. All of these communications are two-way likelywireless network connections. The service provider does not necessarilyrequire physical access to a server but this is illustrated nonethelessas the service provider may be using some sort of hosting for its webAPI or other assets.

Specific examples of the service provider network may include: (i) cloudhosted combination of virtual servers implemented on one-or-morehardware servers, those servers running software pertaining to thisapplication, (ii) the network in (i) with the service provider providingits own servers rather than relying on cloud hosting,

Retailer Network

Retailer network 606 The retailer network is likely operated on a serveror combination of computers and peripherals that is used to shareinformation between parties in the secure self-payment system. There maybe many instances of a retailer network. Each instance and descriptionmay vary from the other as the retailer network is proprietary to eachretail client and some concessions or modifications may need to be made.

A purpose of the retailer network in the secure self-payment system isto provide the service provider network 604 and third party network(s)608 with the information required to perform secure self-payment systemtasks. The retailer network may route traffic and allow or denypermission based on a variety of criteria. General criteria that theretailer may use within its network include accessing device type or IPaccount type (service provider or third party), security clearance basedon third party type (payment service, item lookup service, socialnetwork, etc), or geographical location of the device requesting a queryreply. These are examples as the retailer is free to set its own networkconfiguration. A common embodiment would reject all inboundcommunication from consumer devices, the service provider web API, andthird party services, and synchronize the data with the outbound serviceprovider by polling at set or variable intervals (for instance every 5minutes). All incoming data would come from replies to outbound requestswhich would be recognized as responses to specific requests andaccepted.

Specific examples of interactions involving the retailer network includeproviding the service provider network 604 with item lookup data such asinventory status, pricing or graphical assets, sharing consumerinformation, providing the service provider network with updatedpromotions, or receiving consumer data based the consumer's shoppinghabits as well as secure self-payment application purchase reports fromthe service provider network 604. Interactions with third partynetwork(s) 608 do not necessarily include the service provider but arelikely to relate to information passed through by other parties destinedfor a mutual third party such as payment or item information. The exactconnection configuration and type of information shared between theretailer network 606 and the third party network(s) 608 will rely oneach retailer's needs.

The devices interact as illustrated in FIGS. 1 and 1A and in thecorresponding descriptions herein. In the preferred embodiment, theinteractions feature mostly two-way connections performed through awireless connection, with the exception of the one-way QR-basedexchange. The secure self-payment system functions or communications donot necessarily require physical access to the physical retailer serveritself or to change the server or network configuration hut this isillustrated nonetheless as the secure self-payment system will becommunicating with the retailer network--although, may be accessed via adelayed polling method as described in greater detail above inconnection with FIG. 1A. In a non-preferred embodiment, the one-wayQR-based exchange can be replaced by an alternative one or two-waymedium; for instance NFC could be implemented as a bi-directionalexchange.

One example of the retailer network is a retailer point of sale andinventory management system, implemented on either standard or customhardware, with either a local database or a polling or non-pollingconnection to a cloud database solution. Additionally or alternatively,this network could be implemented for e-commerce rather than a localsolution. The retailer network could also include a cloud-basedinventory management and point of sale system wherein most of theprocessing hardware is located at a remote server location and isaccessed through a wide-area network such as the interne. The retailernetwork could also take the form of a centralized or partiallycentralized network managed by the retailer or third party consisting ofaggregated information from across multiple stores, each of which has alocal point of sale and inventory management system with a polling ordirect connection to said centralized network. Such a network consistsof a combination of routers, firewalls, servers, as well as internal andthird party software solutions.

Third-Party Network(s)

Third-party networks(s) 608. The third-party network(s) is likelyoperated on a server or combination of computers and peripherals that isused to share information between parties in the secure self-paymentsystem. The secure self-payment system may be connected to manydifferent third-party networks. Each third-party network performs adifferent function or is an alternate provider of the same function inorder to enhance the secure self-payment application functionality.

The purpose of the third-party network(s) in the secure self-paymentsystem is to enhance or modify functions performed by the secureself-payment application or to provide functionality that the serviceprovider does not provide itself. The information controlled and hostedby the third-party networks(s) 608 could be social media, paymentprocessing, secure payment data storage or other services. The thirdparty network(s) may route traffic and allow or deny permission based ona variety of criteria such as accessing device type or IP, account type(service provider, consumer or retailer), security clearance based onquery type and accessing device (payment service, item lookup service,social network, etc.), or geographical location of the device requestinga query reply. These are examples only as the third party is free to setits own network configuration.

Specific examples of functions performed by the third-party networkinclude payment processing 418 performed through a payment processornetwork and API, communications with the consumer mobile device 602relating to visual recognition and interpretation of a consumer'spayment card through use of an API and the consumer mobile devicecamera, and communications with third-party network(s) 608 relating topayment or item information as required by the retailer. It should benoted that the secure self-payment system functions and communicationsdo not necessarily require physical access to the physical retailerserver.

Specific examples of third party networks include: (i) a paymentprovider network accessed through POST requests consisting of: XML, JSONor other paradigm for information exchange; (ii) a payment providernetwork accessed through a series of requests in accordance with anexchange protocol or business logic rule-set; (iii) a payment providernetwork accessed through other methods; (iv) a network providing analternative function to payments (for instance OCR on an image) withaccess akin to (i), (ii) or (iii).

Retailer Electronic Device

Retailer electronic device 610 is typically a handheld or stationarypiece of hardware that is traditionally used by retailers to identifyitems by scanning a barcode. The retailer capturing device may be amobile device, the retailer's POS system or any other device that may beused to capture a barcode or QR code or to capture the underlying stringwithin the QR code.

The purpose of the retailer scanning device is to verify a consumer'spurchase through a real world interaction. In the preferred embodiment,this real world interaction involves using the retailer's scanningdevice to read the QR code displayed in-app on the consumer's mobiledevice.

In the preferred embodiment, the retailer electronic device 610 is amobile retailer electronic device with a retailer verification app whichprovides the device the functionality described herein. One example ofsuch a device is a retailer owned iPod Touch augmented with customhardware, such as a Honeywell Captuvo SL-22 sled, that attaches to thephone and provides a 1d-2d imager to augment the camera feed for fastercapture and processing of optical images.

In a preferred embodiment, the retailer device has wide are network(internee) access and a method of displaying the information resultingfrom the communication protocol initiated by a successful scan of the QRcode in concert with the verification app running on the retailerdevice.

In another embodiment, the retailer electronic device 610 is an alreadyexisting hardware POS barcode reader or other device with access to theservice provider's web API and a visual interface such as a screen. Inthis embodiment, the barcode reader is responsible for reading the codedisplayed on the consumer's mobile device, and software within thebarcode reader provides functionality for extracting information fromthe code, and providing this information to the web API. The web APIreceives the information embedded in the code and send a query replyback to the PDS system or reader to display on the screen.

In other embodiments the retailer device 610 is any other device thatsupports a video camera or picture camera for barcode reading. Theretailer device 610 may also be an electronic device with hardware andsoftware that support an alternative exchange, protocol to QR codes,such as NFC communications or other types of wireless communications.

In yet another embodiment, the service provider web API communicatesecure self-payment method sales transactions and sales batches for liveinventory management. The service provider web API may furthercommunicate other information for display or storage on the retailerdevice 610.

A specific, and most often used, example of the interaction performed bythe retailer scanning device is the act of verifying a purchase, andincludes communication with the consumer mobile device 602, serviceprovider network 604, and possibly the retailer network 606 and/orthird-party network(s). The QR code displayed on mobile device 602 iscaptured and interpreted by retailer electronic device 610. Retailerelectronic device 610 sends a query to the service provider network 604asking whether the QR code corresponds to a legitimate purchase (step428, as discussed in connection with FIGS. 4A and 4B, above). A reply issent back to 610 retailer scanning device with an answer. The retailerscanning device 610 then displays either a legitimate purchase receipt(per step 430) or a request to reseed the information or a “no match”result (per step 432). Depending on the retailer's individual needs, thescanning device may also transmit some information relating to pricingor inventory updates to the retailer network 606 or third-partynetwork(s) 608.

In another embodiment, the interaction by the retailer electronic device610 may be used to perform an item exchange (per step 324). Thisfunction makes use of the same connectivity but depending on theretailer's own configuration it may require internal retailerconnectivity and interactions not illustrated here.

In the preferred embodiment the connection between retailer electronicdevice 610 and consumer mobile device 602 is a physical real worldinteraction involving the retailer's electronic device and the retailerverification app being used to capture the displayed QR code directlyfrom the consumer mobile device. Connections to the service providernetwork 604, retailer network 606, and third-party networks 608 are alsoconducted via two-way likely wireless connections. In a non-preferredembodiment this connection may be one-way or two-way based on thetechnologies in use and implementation details of those technologies. Inaddition, the nature of the QR code can be changed to allow for caseswhere the retailer wireless connection is disabled.

In other embodiments, the connection between the retailer device 610 andconsumer device 602 may still make use of a real world physicalinteraction with the consumer's mobile device but the retailer device610 may be a retailer POS system scanning device such as a barcodereader or NFC terminal or other hardware.

In yet other embodiments, the connections between the retailerelectronic device 610, the service provider network, and the third-partynetwork(s) 608 are not wireless. The exact configuration of suchembodiments is dependent on retailer preferences and devicecapabilities.

In the preferred embodiment, specific examples of the retailer scanningdevice are mobile devices such as an Apple iPhone, Apple iPad, AppleiPod Touch, Samsung Galaxy S3 or Samsung Galaxy Note. These devices aremodified to include software in the form of an application or “app” thatprovides the devices with the functionality necessary to carry out theself-payment systems and methods described herein.

In other embodiments, specific examples of the retailer scanning deviceare POS hardware systems such as the IBM SurePOS with a compatiblebarcode/QR code reader and access to the service provider web API.Again, these devices are modified to include software in the form of anapplication or “app” that provides the devices with the functionalitynecessary to carry out the self-payment systems and methods describedherein.

Non-Mobile Consumer Device

Non-Mobile Consumer Device 612 is a device that is typically not mobileand cannot be used by a consumer in various locations. Generally, thenon-mobile consumer device runs an OS, can install applications and hasinternet access. Typical components include an input device such as akeyboard or touch screen and a visual interface such as a screen ormonitor. The non-mobile nature of the device relates to the fact thattypically it does not operate on battery power or is too large to beportable by the user from one place to another.

The purpose of the non-mobile consumer device for secure self-paymentsystem functionality is to allow the consumer to perform certain tasksthat do not necessarily need to be performed in-store. The non-mobileconsumer device is not a necessary component of the secure self-paymentsystem and is used by the consumer as an optional convenience. Thenon-mobile consumer device has access to the service provider web APIvia an internet connection and web browser as well. While it is unlikelythat this device is not intended to be used to perform an in-storetransaction, it is possible that such devices may provide access to aconsumer's account or be able to perform some specific functions in theout of store flow 334.

Specific it that may be performed through use of the non-mobile consumerdevice include entering profile and preferences 308, and viewingpurchase history through the use of a web browser, the consumer's logincredentials to the service provider web API and a connection to serviceprovider network 604. Other interactions include the ability to additems to cart 336 through the use of the fixed device input component orcamera component and the connection to service provider network 604.Interactions with third party network(s) 608 may include the request foritem information not accessible by service provider network 604 or tosecurely edit payment information. Generally, the specific functions ofthe non-mobile consumer device are preformed through a login to the webAPI.

In one embodiment it is possible that the non-mobile consumer deviceinitiates a purchase and completes payment for an out-of-store purchasewith service provider network 604. Service provider network 604 sends averification QR code and purchase receipt for display in the consumer'ssecure self-payment application on consumer mobile device 602 fordisplay in-store.

The non-mobile consumer device interacts with service provider network604 and third party network(s) 608 using a wireless connection. Theconsumer's internet may not be wireless itself, but the consumer willnot have direct wired access to either of these parties.

Specific examples of a non-mobile consumer device include a desktop PCsuch as a Dell Inspiron, or a smart TV with a web browser such as an LGSmart TV.

Request Processing in Networks

FIG. 7 is a diagram showing the process steps involved in fulfilling arequest from the web API of the service provider network to the retailernetwork, according to an embodiment of the invention. Note that in thecase of the polling solution mentioned in FIG. 1A, the process of thisfigure is not used but rather all data entering the retailer networkcomes as the response to an outbound request from the retailer network.In such a case, the polling software would run on the retailer serverand manage a series of business logic rules for directing messages toand from hardware in a manner akin to this process.

The process begins at step 702, “Request Enters Retailer Network.” Inthis step the service provider's web API hosted on the service providernetwork 604 generates a request and sends it outbound for the retailernetwork 606 to process. A common example, which will be tracedthroughout this description, is an inventory update. Other examples mayinclude updating promotions, item prices, consumer profiles or pushingsales reports to the retailer. This request is routed to an appropriatemachine on the service provider network 604 and sent out from a specificInternet protocol (IP) address. This request would originate on theservice provider server and pass to the retailer network through a widearea network.

At step 704, “Identified as Service Provider Network Request,” therequest is sent to the IP address for the retailer network 606 by usingany one of well-known network protocol communication standards, such ascURL and HTTPS, in a standard process that includes confirming theidentity of the network, such as by confirming that the network is usinga signed and verified certificate. The port to which the request is sentdepends on the specific retailer configuration and permissions. Thisidentification is executed in a back-and-forth handshake between theservice provider server, the retailer server and the signing authority'sserver.

At step 706, “Request Comes from Correct IP on Valid Port,” the routeron the retailer network identifies the service provider network'srequest as having an IP address permitted to use the specific port onwhich the request is sent and, allows the request to enter the retailernetwork on the port. In the preferred implementation this step isinstead addressed by the previous handshake using the Signing Authorityto Confirm the Sender's identity.

At step 708, “Routed to Server Responsible for Request from ServiceProvider” the retailer network routes requests to appropriate servers onthe network. The retailer network is already configured to send theserequests. The server to which the request is sent may confirm theservice provider's network certificate and evaluate the request. Thiscould be a direct connection (already at the server), a connection to aspecific virtualized server, on the same hardware as the current server,or a physically different server.

At step 710, “Generates Sub-Requests,” the request is processed by theappropriate server and this processing generates sub-requests to berouted for processing. In the inventory update example, the machine towhich the service provider network's request is sent generates an updatecommand for the retailer inventory database, which could either be sentto the POS API or to the retailer database directly. A specific examplewould be a retailer having its inventory database on one server and itstransaction database on another server. If the inbound request were toadd a transaction and an inventory adjustment, this would create twoseparate requests and send each to the appropriate server on thenetwork.

At step 712, “Routes Sub-Requests,” sub-requests are sent as determinedby the processing on the server in 710. For the inventory example, theinventory database is updated typically by a decrement command. For thetransaction example, the database would be sent a create recordinstruction in the database's preferred implementation language (forinstance SQL) with the fields and values matching the information sentin the add transaction sub-request

The above example instructions also have routing information and/orsecurity information/encryption over the retailer network, or in thecases of third-party services it has routing information and encryptionto connect to the remote service. The request also has information aboutwhere to return results.

At step 714, “Aggregates Sub-Requests,” the results of the sub-requestsare returned to the retailer network 606 and routed to the machineresponsible for the specific request by the router in a process similarto steps 702-708 in cases where the request went to an external process,or by permitted connections between machines, such as those with validsecurity certificates and IP addresses, in cases where the request isinternal. “Returned” as used in this context means “is sent as the replyto the request” These returns may be treated as outbound communicationsby the retailer server rather than inbound, and generally have differentprocessing rules or rejection rules when coming back through security.In cases of delays sub-requests may be sent again, or the entire requestmay timeout to either reprocess or have a timeout result sent back tothe service provider network 604 for a decision on what to do. Therequests are processed by one or more retailer servers, and may includethe use of virtualized and physical hardware.

At step 716, “Generates Response,” in the event that the criticalsub-requests conclude successfully the request is tagged a success andrelevant information is sent back. For successful requests where somesub-requests fail, those sub-requests are re-tried after sending asuccess message to the user. In the event the requests continue to fail,a warning/notification may be sent back to the service provider network,typically through a status code on the response to the request.

At step 718, “Routes Response Outbound,” information is sent back to theself-payment network using standard communication protocols, such ascURL and HTTPS, confirming the service provider's certificate and theretailer connecting to the self-payment network on an authorized port,using the previously identified confirmed encryption keys (possiblyreconfirming the identity).

At 720, “Response Leaves Retailer Network for Service Provider Network,”the request result is sent to a permitted port on the service providerand is routed back to the self-payment server that made the request.

FIG. 8 illustrates the detailed steps taken for a consumer devicerequest to the self-payment server, according to an embodiment of theinvention.

At step 802, “Request Enters Service Provider Network,” the consumer'smobile device 602 or non-mobile device 612 generates a request for theservice provider's network to process. This request is routed to anappropriate server on the service provider's network.

At step 804, “Identified as Request from App,” the request is passed toa server running the web API on the service provider network possiblythrough any number of the following: a firewall, a cache manager, a webrequest manager, a server configuration, an app preloading tool, a loadbalancing tool and sent to an instance of the web API running on theservice provider network 604 for processing.

At step 806, “Request Comes, is on Correct Port,” the router on theserver identifies the request as valid and allows the request to enterthe service provider's network, routing it to a server for processing.

At step 808, “Processes Request including Consumer/User Identification,”the web API checks the consumer ID for permissions to the specific data.The web API confirms the request and begins processing the request.

At step 810, “Generates Sub-Requests,” the service provider serverprocesses the request and generates sub-requests for processing. Thiscould be a local port communication or external routing to eitherthird-party network(s) 608 or the retailer network 606.

At step 812, “Routes Sub-Requests,” sub-requests are sent as determinedby the self-payment web API. Exact sequences of commands will varydepending on the nature of the request. The processed request reply isrouted back to the self-payment server for further processing.

At step 814, “Aggregates Sub-Requests,” the results of the sub-requestsare returned to the self-payment network and routed to the machineresponsible for the specific request. In case of delays, sub-requestsmay be sent again, and/or the entire request may timeout to eitherreprocess or have a timeout result sent back to the consumer device fora decision on what to do.

At step 816, “Generates Response,” in the event that the criticalsub-requests conclude successfully, the request is tagged a success andrelevant information is sent back to the consumer device 602 or 612. Forsuccessful requests, where some sub-requests fail, those sub-requestsare re-tried after sending a success message to the consumer device. Inthe event those sub-requests continue to fail a warning/notification islogged.

At step 818, “Routes Response Outbound,” information is sent back to theconsumer device using standard communication protocols, such as cURL andHTTP, confirming the ability of the consumer's device connecting to theservice provider's network on an authorized port, using the previouslyidentified confirmed encryption keys.

At step 820, “Response Leaves Service Provider Network for ConsumerDevice.” the request result is sent to the consumer's mobile device 602or non-mobile device 612 using a permitted port.

The following describes components of certain physical devices that maybe used in a secure self-payment method transaction. Each device typethat is used has many configurations and may include additionalcomponents or omit certain ones listed here. These illustrations are“typical” device examples only, and are not intended to limit theinvention to any particular configuration described below. Thedescriptions below are best understood with reference to FIGS. 9 through12.

Consumer Mobile Device Example

FIG. 9 is a diagram showing components of a consumer mobile device 620to be used with the secure self-payment method, according to anembodiment of the invention. Although a smart phone 900 is shown as anillustrative embodiment of a consumer mobile device, the consumer mobiledevice is not limited to smart phones and may very well be a pair ofsmart glasses or a watch. The smart phone 900 is displayed as an exampleof one specific type of device that includes all the listed components.In reality, a consumer mobile device 620 may include only some of thesecomponents and may also have additional ones not illustrated. Theconsumer mobile device 900 is the main means through which the secureself-payment application is made available to the consumer and is usedto perform secure self-payment system tasks. The components listedherein may be similar to the mobile device that the retailer uses to runthe retailer app, as further described below.

Display/Input Components 902. The display is responsible forcommunicating information to the consumer. Through the display 902 theconsumer views information communicated through the secure self-paymentapplication and the device OS. The display 902 also gives the consumerfeedback based on his or her interactions with the device. As a consumerenters in data, the display 902 shows a digital representation of thedata he or she wishes to enter and/or are entering. An example of thisis the typing in of one's credit card number. As each individual numbercharacter is selected by the user, the display visualizes this input anddisplay it in a designated field.

The display 902 is also the main method of visualizing the inputs madeby the user and communicating messages and data sent by the serviceprovider's web API or other parties.

In this illustration, the display also serves as a means for permittingthe consumer to input data into the mobile device, and into the mobileOS and the secure self-payment application. Other well-known input meansmay be used for the consumer mobile device either in connection with oras an alternative to the display, such as a tactile device (such as adevice keypad), means for voice or speech-to-text recognition, means fordetecting physical movements made with the device, or a hardwareattachment. The most common hardware components used as an input deviceinclude a tactile keypad or keyboard, or the display itself via a touchscreen.

Location Sensing Components 904. The location sensing components 904 areused for what is commonly known as “location services.” The consumermobile device 900 via installed software and third party services canprovide the consumer device with the ability to sense a specificgeographical location or area where the consumer's mobile physicaldevice is located. In the preferred embodiment, the secure self-paymentapplication uses location information mainly for purposes relating tosending and crafting geographically targeted offers and itemsuggestions, to notify the consumer that he or she is near or in asecure self-payment method-enabled store, or to enable the consumer tosearch for nearby retailers.

Location sensing components for enabling a mobile consumer device toprovide location information are well known in the art, and the exactcomponent or software responsible for this function varies by devicemanufacturer or use case. Commonly used methods of determining a deviceuser's location include GPS or Wi-Fi.

Internet Connection Components 906. Internet connection components areused by the mobile consumer device 900 to access information that is notstored directly on the mobile device. Through the internet connectioncomponents 906, and with the proper permissions, the consumer mobiledevice 900 can access the internet and local or other networks. Themethod of access varies based on case, network, service provider,hardware or other factors. Common mobile methods of access to networksand the internet include 3G, LTE and Wi-Fi. The secure self-paymentapplication requires the use of this when processing many requests suchas item lookups and item suggestions.

Camera(s) 908. The consumer mobile device 908 may have more than onecamera. The device camera(s) 908 are used to capture an image or videoof physical items and then create a representation of them in an imageor video format viewable to the user or to be used with certainthird-party services. The secure self-payment application may use cameracomponents for: identification of physical items via barcode or otheritem identifiers so that pricing may be looked up or the item added tothe shopping cart; to capture payment card information through the useof a third party API or SDK or to take an image of the consumer so thatthe image may be associated with the consumer's profile

Light 910. The device light 910 is used to adjust the brightness of thearea in front of the device cameras) 908 to provide a more suitableenvironment for image capture. This light 910 may be used to aid in thecapture of an item barcode image for item identification purposes.

NFC Component 912. The NFC, “near field communications” component istypically used as a method of conducting secure transactions between twoNFC-enabled devices. Typically, the NFC component is internal to thedevice but may also be an attachable sticker or tag. To perform atransaction, two compatible devices such as a mobile device and a POSterminal must be held around 4 inches from each other so that a smallpacket of data may be transmitted. In some embodiments, thesetransactions may be data sharing between two people such as photos orstored contacts or monetary such as a funds transfer between two mobilewallets or an in-store purchase of goods or services. The secureself-payment application may use the NFC component to read the token, orstring linking to a database entry which is represented by the QR codedisplayed on the consumer receipt. In embodiments that use NFC tocapture the token, the QR code itself may be an optional component thatprovides a standard self-payment system feature and provides analternate reading method for non-NFC devices. In this case, the consumerdevice NFC chip is responsible for transmitting the string to theretailer device NFC chip.

Retailer System Example

FIG. 10 is a diagram of a type of retailer point-of-service (“POS”)system which may be used with the secure self-payment method, accordingto an embodiment of the invention. The POS system 1000 is acomprehensive hardware and software combination that many retailers usefor front and back office functions. The most common use for a POSsystem is to track sales and identify inventory items.

For purposes of explanation, the POS system 1000 described herein isabstracted into four components. It is understood, however, that otherPOS systems with additional or fewer components, or with componentsdifferent from those described below may he used in connection with thesecure self-payment systems and methods described herein.

POS System 1000 includes front-end hardware and software components1002. The POS front-end hardware and software components 1002 includethe hardware and software responsible for the standard operation ofclassical POS systems, other than the server components 1004 discussedbelow. These hardware and software components may comprise well knowncomponents that enable the POS system 1000 to perform standard functionsrelated to, for example, tracking sales, identifying inventory items.Specific examples of POS hardware systems and components include the IBMSurePOS system, a Symbol or Honeywell laser barcode scanner, and an APGPOS Podium Cash Drawer. Specific POS software includes RetailPro 9 POS,Lightspeed POS, and Quickbooks POS Pro 13.

POS system 1000 also includes a server 1004 for inventory, transactions,and customer relationship management (“CRM”). The server 1004 contains aPOS database which stores sales transaction information, inventoryinformation, and customer information. The server 1004 may also containa supporting API that permits additional functions such as enhancedinventory descriptions, live inventory updates between the brick andmortar store and an online web presence, or web site updates such asshipping information through third party integration such as aneCommerce toolkit. This server will accept read and write requests fromboth the front-end hardware/software 1002 and the service providernetwork 1006.

The service provider network 1006 is the network that runs thesupporting web API for the secure self-payment application. The serviceprovider network 1006 manages requests from the secure self-paymentapplication running on the consumer mobile device, including requestsfor purchases. In another embodiment, these purchase requests can bemanaged by 1004 where the server 1004 is equipped with supporting APIfunctionality. The service provider network 1006 optionally controls adatabase to store information that might not be contained in the POS,such as information related to enhanced item descriptions or secureself-payment method exclusive promotions.

Retailer QR verification devices 1008 are examples of the retailerelectronic devices 610 that the retailer uses to “spot check.” A spotcheck is the physical act of the retailer verifying a consumer'spurchase. Traditionally this act is done through visual inspection of apaper receipt and the items the consumer is taking out of the store. Inthe secure self-payment system case, this involves the use of theretailer's capturing device 610 capturing and verifying the QR codedisplayed on the consumer mobile device 602 to check for a matchingtransaction.

As noted herein, the self-payment system and method in its variousembodiments may rely on one or more networks. These networks maygenerally consist of a local area network (“LAN”) connected to a widearea network (“WAN”) through one or more routers. Each network mayinclude one or more server machines, physical and/or wirelessconnections, routers and firewalls. Each server takes the form of amachine with a specific local address on the network, and each serverincludes hardware and software that enables it to run programs, manageinformation, and process requests. In particular, each server runsspecific programs that receive, process, and forward message requests,as well as to performs tasks specific to that particular network (asfurther described with respect to each network). In addition, eachserver includes storage means to process, store, and manage specificinformation (typically through databases and application caching).

Each network may further include one or more routers, which are devicesfor directing traffic to specific machines in a Local-Area Network(typically a wired network but may have wireless links). The servers androuters may further include firewall software, which are programs forthe restriction of communications to a network (when run on a router) ora server (when run on the server). Each network may utilize or includeportions of the Internet, which is generally classified as a wide areanetwork with relatively open communications and low security.

Retailer Example

FIG. 11 is a diagram of a retailer network 1100 which may be used withthe secure self-payment method, according to an embodiment of theinvention. The retailer network 1100 includes a wide area network (WAN)portion 1102. This WAN portion 1102 can generally be any distributednetwork that is either open access or non-local. In the preferredembodiment, the WAN portion of the retailer network 1100 is mosttypically the internet.

The retailer network also has a local area network (LAN) portion thatincludes one or more routers 1104. Each router is a piece of hardwarewith corresponding software that functions primarily to determine whichservers 1106 to send requests to. The secondary function of each routeris to provide a software firewall that can reduce traffic internally byblocking bad requests before routing them on the LAN.

The LAN portion of the local area network also includes one or moreservers 1106. The servers 1106 run software to support the networkfunctionalities described herein. In the case of a retailer networkthese servers 1106 typically include hardware and software that enablesthem to perform functions related to inventory management, CRM, paymentprocessing, returns, and transaction history. As an example, theretailer LAN network typically has a server and POS system connected.This server and POS system controls the retailer's proprietaryinformation relating to items, pricing, HR, or other functions relatingto running a brick and mortar store. The POS system may be connected toa database with the above information and may run supporting API toaugment specific functions such as providing additional item informationor connecting to other non-internal sources of information.

Service Provider Network Example

FIG. 12 is a diagram of the service provider network to be used with thesecure self-payment method, according to an embodiment of the invention.

The service provider network 1200 includes a WAN portion 1202. The WANcan generally be any distributed network that is either open access ornon-local. In the preferred embodiment, the WAN portion of the retailernetwork 1200 is most typically the internet.

The service provider network also has a LAN portion that includes one ormore routers 1204.

The LAN portion of the service provider network also has one or moreservers 1206 that run software to support the specific functionality ofthe service provider network 1200. In the case of the service providernetwork 1206 these servers 1206 typically include hardware and softwarethat enables them to perform functions related to serving a webpage, anAPI for a mobile device OS application, a webserver for domainmanagement, an operating system for managing the server configuration,one or more database systems for managing the data generated by thesetasks, socket configurations for request redirection, deploymentinfrastructure, remote back-up infrastructure, load balancing tools,analytics tools, and other functionalities.

In the preferred embodiment, the secure self-payment method is used incombination with a verification app used by the retailer, typically aretail sales associate, for the purpose of successfully verifying aconsumer's purchase. The service provider makes this verification appavailable to its retail clients by making the app available for downloadover a network via a secure portion of the service provider's website,or by providing the retailer with storage media containing theverification app and from which the retailer can install the app onretailer POS and mobile devices. For security purposes, the serviceprovider generally limits access and use of the verification app toretailers. For example, the service provider may require that a retailercreate a separate, secure retailer account with the service provider,and may limit access to the verification app to those retailers who havesuch an account. Limit to the verification app may be securelycontrolled because it serves a different purpose than the self-paymentapp made freely available to the public. In contrast, the verificationapp may not be publically available to download on a general “appstore,” The retailer verification app may also require the use of loginchecks in addition to a username and password such as verification ofthe device ID, a retailer login or geographic information.

Example Consumer Device and Self-Payment Application Screen Views

FIG. 13 is a diagram illustrating the process involved in successfullyverifying a consumer purchase through use of the retailer self-paymentverification app, according to an embodiment of the invention. Theretailer verification app may display an initial welcome screen 1302once the secure self-payment system has authenticated the retailer. Themain function of the welcome screen 1302 is to provide the retailer withretailer specific functions, most notably a method to verify and match acode, such as a QR code, on the consumer's receipt to a salestransaction. Upon prompting the verification app to capture a QR codedreceipt 1304 the retailer verification app presents the retailer with aninterface to identify the QR code displayed on the consumer's device.This requires a real-world physical connection involving the retailermobile device running the verification app and the consumer's mobiledevice running the secure self-payment application and is similar to themethod in which the consumer identifies an item in the secureself-payment application by scanning a barcode, QR code, or otheridentifier. In the preferred embodiment the retailer device operatingthe verification app has a camera, along with a processor and softwareadapted to operate the camera to facilitate scanning of a unique code,such as a QR-code, and to scan or otherwise capture an image of thecode. The retailer device may further comprise a display along withhardware and software adapted to display a real-time image of the imageto be captured by the camera in order to facilitate scanning of thecode.

Once the retailer has utilized the verification app to capture, the QRcode on the consumer's device, the verification app operates at 1306 tosend a query regarding the QR code to the to service provider's web API.The verification app sends a query to the service provider's web API toretrieve the purchase information corresponding to the QR code aspresented by the consumer. This is further explained in FIGS. 4A and 4Band is part of the spot check procedure 426 and includes 428, 430 and432. If the retailer captures the QR coded receipt displayed on theconsumer's mobile device or a paper print out of the QR coded consumerreceipt, the retailer's device displays information that is referencedby the successful transaction. It is the matching of the QR code throughthe use of the service provider's web API and the corresponding displayto the retailer device that is the confirming step that can give theretailer confidence that the in-aisle consumer payment transaction wassuccessful and legitimate. Each retailer can customize how and where andwhether to verify every transaction or can set up his or her own custombusiness process for verifying selected transactions based on theretailer chosen rules and processes.

Upon a successful query, the verification app presents the retailer witha confirmation screen 1308. The service provider's web API pushes to theretailer verification app the purchase information that was recordedwhen the consumer submitted payment and the QR code was originallygenerated 1310. The retailer verification app displays portions of thepurchase information that may assist the retailer with verification ofthe purchase, such as the items and the quantity purchased, along withthe consumer's identification information. The confirmation screen 1308provides the retailer with an “Approve” function 1312, which theretailer uses to signal to the verification app that the retailer hasreviewed the purchase and verified the details thereof.

Following activation of the “approval” function, at 1314 the retailerverification app sends information to service provider's web APIindicating verification and approval of the purchase. The retailerverification app notifies the secure self-payment system that theretailer has approved and inspected the purchase. At this point, the webAPI may mark the purchase as approved. The web API may also update thepurchase information in the data record to indicate that the purchasehas been approved. In addition, the web API may send a notification tothe consumer's secure self-payment app with a timestamp of approval orreceipt verification attempt, which the self-payment app may then storein connection with the consumer's receipt. In the preferred embodimentthe QR code is only valid for one purchase transaction and cannot beused twice for the same task. For example, if once the QR code has beencaptured and approved originally, the associated data record is markedas approved and is otherwise recorded in the retailer's system; as aresult, if a consumer or retailer attempts to capture the same QR again,the web API will notify the retailer that it cannot be approved again.In this case, the web API would return information to the retailer'sverification device stating that the information linked to by the QRcode has already been approved and no further action relating to theapproval process should be taken. In the use case where spot checks arenot universal, a geofence (coordinate region on a map) could be used forthe same functionality. In this case, the action of the device leaving adesignated area in combination with the location sensing component ofthe mobile device would internally mark the receipt as having left thestore. In such a case, the retailer should apply its loss preventionprocedures if a customer tries to use the receipt twice. In thisimplementation, the QR code itself does not change on the consumerdevice; the database software running on the service provider serverupdates the transaction with details about the consumer device havingleft the store (where the locations services on the consumer device areenabled) or the QR code having been used to complete a spot check and nolonger being valid for further spot checks. When the query for thattransaction is sent by the process that occurs on the retailer deviceafter capturing the QR code, the updated information is sent with thenew result.

After activation of the “approval” function, the verification apppresents the retailer with an approved screen 1316. The web API sendsback a message to the verification app that it has received the approvaland will mark the purchase as approved 1318. On subsequent verificationattempts by other retail associates, the verification app may Show theapproved screen right away instead of requiring an “Approve” 1312action.

Although the functionality of the verification app has been describedabove with respect to a purchase verification, the retailer verificationapp may include a “retailer dashboard” which provides additionalfunctionality, such as giving the retailer access to data relating tototal sales, promotions, and consumer behavior. For such functionality,the retailer verification app may include logic for accessing theretailer's POS system and related databases which store and manageinventory, sales and transaction information, promotions and marketing,and consumer information.

In some embodiments, the retailer verification app is capable ofperforming an associate-assisted in-store payment. In this case, theverification app contains similar functionality as the self-payment appof the consumer's mobile device, and the retailer mobile devicecontaining the verification app is operated in a similar fashion as theconsumer's mobile device with the self-payment app in order to handle aself-checkout process. In certain embodiments involvingassociate-assisted in-store payments, the payment process may differ inthat the consumer is not required to have a secure self-payment accountfor the most basic payment function: instead payments are performedusing the retailer's service provider account.

In other embodiments, the retailer verification app containsfunctionality that allows it to be used as an aid for the storeassociate when helping a consumer in-store. In particular, theretailer's verification app may be used for item lookup queries,promotions, or to better understand the consumer's past shopping andbrowsing history.

In yet another embodiment, the retailer verification app is not offeredas a stand-alone application but is instead bundled in with POS softwareor other retail hardware or software through the use of a retailerservice provider API.

Following are descriptions of app screenshot with respect to theself-payment app as displayed on the consumer mobile device. Thesescreenshots are for illustration purposes only and do not represent thefull feature set that may be available in the final product.

FIG. 14 is an example menu which may be displayed on the consumer'sdevice in-app, according to an embodiment of the invention. A retailerbranded info screen, such as the one set out in FIG. 14, may be a firststep to performing many functions possible from the secure self-paymentapplication app. Key features displayed in FIG. 14 include item scanningto be used to identify an item that the consumer wishes to purchase1402, a profile section used to view the consumer's previous purchases,payment methods, or to add personal information 1404, and the consumer'sshopping cart used to view the items that the consumer has alreadyidentified as those he or she wishes to purchase 1406. Other featuresmay include a variety of functions that may he performed through athird-party API. On this mock up screenshot these include social medialinks 1408. Map 1410. Directions 1412, Internet 1414, and Scan 1402. Itis possible that other functions may also make use of third-party APIs.

FIG. 15 is an example payment method interface which may be displayed onthe consumer's device in-app, according to an embodiment of theinvention; this figure provides an illustrative screen of some possiblepayment methods that the service provider may offer for use in app.According to the embodiment shown, the payment screen is visible uponcheckout 322. A similar screen may be visible upon the creation of aconsumer profile 308. Due to the wide variety of possible paymentoptions it may be necessary that the secure self-payment method usemultiple payment processors. In the case illustrated in FIG. 15, theconsumer has selected his or her Visa credit card as his or her paymentcard of choice 1502. The consumer also has several payment methodsavailable 1504 that he or she has inputted previously during a checkout322 or profile update 308, and has the ability to add a new paymentmethod 1506.

FIG. 16 is an example QR-coded receipt as displayed on the consumer'sdevice in-app, according to an embodiment of the invention. This is anillustrative QR-coded receipt which is generated by the secureself-payment app after the consumer's payment method has been approvedand the purchase has completed at step 424. This QR-coded receipt isused by the consumer as proof of the completed transaction and may alsobe used for record keeping purposes by the consumer and is available ondemand in the consumer profile section of the secure self-paymentapplication. The self-payment web API generates a QR code and creates areceipt to be displayed in-app that includes the QR code, itemspurchased, loyalty information, store information and other informationrelevant to the transaction.

1602 is an example of an itemized receipt along with a QR code 1606 thatmay be captured by the retailer's device. After capturing the QR codedreceipt displayed on the consumers' mobile device and assuming amatching transaction is, found by the web API in the service provider'snetwork, the retailer's device then displays relevant purchaseinformation as illustrated in FIG. 13. This code is verified by theretailer in a spot check process 426 through the use of a real worldphysical connection involving the retailer's electronic device runningthe retailer verification app, capturing the QR-coded receipt from theconsumer device and running the secure self-payment application and isused for verification purposes only. FIG. 13 describes one method inwhich this may be done.

1604 is the same screen viewed on the consumer device after the consumerscrolls down. This screen displays additional information such as thetotal purchase amount and applicable discounts 1608, and applicableloyalty and retailer information 1610.

In one embodiment, the service provider makes available the QR codedreceipt for use with the Apple Passbook app. Apple Passbook integrationis beneficial to the consumer in that it provides a method of verifyingthe QR code that allows the consumer to take fewer steps to display theQR code. This integration is particularly useful if the consumer spendsadditional time at the retail store such that his or her device enters“sleep” mode and under normal circumstances the secure self-paymentapplication would need to be opened once again.

FIG. 17 is an example device lock screen displayed on the consumer'smobile device when the secure self-payment method is integrated withApple Passbook, according to an embodiment of the invention; this screenis an example of how the secure self-payment application can integratewith Apple Passbook. Passbook integration is optional for core secureself-payment application functionality but provides extra convenience tothe consumer while becoming a more time saving purchase verificationmethod. Using location services, Passbook can determine whether theconsumer is near or in the retail store and as per the consumer'ssettings will notify them through a screen similar to this one. Thelocation-sensing functionality of Passbook allows it to detect if theconsumer is currently at a GPS coordinate within a geofencecorresponding to a retailer where the consumer has made a purchase andreceived a receipt through the self-payment application. Havingconfigured the self-payment app to display transactions in Passbook, theconsumer may designate that the self-payment app should displaynotifications for these retailers in Passbook when the consumer deviceis near a physical location for these retailers. In the example show inFIG. 17, the consumer has completes a transaction with a specificretailer and has configured the self-payment app to displaynotifications from the app in Passbook. As a result, when the consumeris near a physical store location for the retailer, Passbook displaysthe self-payment app notification 1702 on the lock screen of theconsumer device.

By swiping left or right on the bar displaying the “SP” logo 1702, themobile device opens Passbook and displays the most recent QR-codedreceipt from that location. If the consumer has multiple purchases, thereceipts corresponding to those purchases are displayed in reverse orderof time of purchase in Passbook. In the preferred embodiment, theconsumer profile settings in the secure self-payment application andApple Passbook allow only the QR code that corresponds to the purchaseto be displayed directly on the device lock screen. In this case, theretailer uses its scanning device as with a regular secure self-paymentpurchase method transaction but the consumer is not required to unlockhis or her device and reopen the self-payment application.

FIG. 18 is an example interface displayed on the consumer's mobiledevice and viewed in the Apple Passbook app when the secure self-paymentmethod is integrated with Apple Passbook, according to an embodiment ofthe invention.

Once Apple Passbook is launched, the transaction-specific QRcoded-receipt 1802 is displayed. The method in which Apple Passbook islaunched determines whether or not other retailers or Passbook apps willbe visible on the screen. If the app is launched from the lock screenwhile near a secure self-payment retailer, only the transaction-specificQR-coded receipts will be visible. If launched otherwise, other Passbookpasses may be visible as in FIG. 18. In general, however, once theconsumer has set the correct options in his or her secure self-paymentapp profile and settings, the secure self-payment app and Passbook areintegrated to provide the functionality described here. The exactappearance of the display interface and method of in-app QR coderetrieval depend on the consumer profile and settings as well asbehavior and permissions of the third-party Passbook API.

The screen shown in FIG. 18 displays a functional QR code, in that it isidentical to the QR code on the receipt accessible via the non-Passbooksecure self-payment app. Accordingly, the QR code shown in the Passbookdisplay in accordance with FIG. 18 may also be scanned by the retailerand used as purchase verification. In certain embodiments, once the QRcode is verified by the retailer's scanning device, the secureself-payment system will instruct Passbook to mark the code as used orkeep a tally of how many times the QR code was captured. In otherembodiments, the outcome of the code being used will be displayed on theretailer side, mitigating the need to show such information on theconsumer side.

FIG. 19 is an example used to define the key characteristics of a QRcode, according to an embodiment of the invention, and in that regardillustrates certain features of QR codes.

A QR Code is a type of matrix bar code that may store rich informationor link to a web page with information and may be read by smart phones,tablets or other mobile or fixed scanning devices. The code consists ofblack or colored modules arranged in a square pattern on a whitebackground. QR codes look like barcodes (due to their black and whitecoloring and square shape), but when captured with a smart phone, tabletor other mobile device, they reveal encoded information. The QR code canstore over 7,000 numeric, or 4,000 alphabetic characters.

A QR code which is displayed on a consumers' mobile device can be readby a smart phone, tablet or other fixed or mobile device that isequipped with a camera or scanner, an app having functionality or manualentry code that allows it to decipher the QR code, and internet orwireless area network access. In typical cases, the person decipheringthe QR code only needs to open a code-reading app, scan or take apicture of the QR code using a camera which is accessible through acode-reading app, and then the code-reading app will retrieve the datalinked to the QR code such that this data will automatically appear forthe person on his or her mobile device. In the preferred embodiment, theQR code is processed by a camera, through progressively attempting torecognize the data in the code. The process automatically terminateswith results when it successfully identifies and decrypts the QR code.

The secure self-payment method requires the retailer to capture the QRcode displayed on the consumer's device with a device with access to aconnection to the service provider API for purchase informationretrieval. In the preferred embodiment, this device is a retailer mobiledevice running the retailer verification app. In other embodiments, thismay be a fixed or mobile scanner equipped with the ability to read QRcodes and to connect to the service provider API either directly orthrough an intermediary such as the retailer's POS system.

Additional Features

In certain embodiments, the secure self-payment application may includeoptional features. These optional features may be implemented inspecific cases per the retailer's or consumer's request, through the useof third-party APIs, or through functionality included in some of theremaining 20 modules in the service provider's suite. The featureslisted below provide an illustration of the flexible and modular natureof the secure self-payment application in its entirety.

Each of the optional features described below is provided via one ormore optional application-specific modules that may be included with theself-payment app. Each of these modules contains the requisite softwareto carry out the functionality described in connection with thefeatures. In addition, where applicable and as further described below,other self-payment system components, including the retailerverification app, retailer mobile device, service provider network(including web API), and retailer network, may contain additionalhardware and or software to accommodate the additional functionality ofthe software modules that implement the optional features describedbelow.

Personal Associate. Separate from the self-payment method but part ofthe service provider's self-payment application suite is a personalassociate option. This personal associate option may be used byconsumers to contact an associate at any time during the shoppingexperience or from outside the store to request a fitting appointment,advice or other interaction with a retail associate. Through thepersonal associate option, consumers may confirm a “Personal ShopperAssistant” option from the following choices:

(a) Choose a personal associate Used by consumers who are familiar withthe retailer's store associates. Consumers may choose a specific knownassociate by name.

(b) Choose any sales associate—To be used by first-time consumers, orthose who do not have a favorite sales associate. This may display alist of currently available or all retail associates for selection.

(c) Decline the option to have a personal sales associate connected toyour shopping visit(s). This choice may be used by consumers in thestore who would like an uninterrupted shopping trip. This will notifythe retail associates via the retailer electronic devices that theconsumer does not require assistance in selecting items or advice onproduct selection.

The personal shopper features are provided via a personal shoppersoftware module that includes the functionality needed to carry out theabove steps. The software module displays the above choices and promptsthe consumer to select one of the above choices. Once the consumerselects one of the above choices the personal associate module makes useof a similar or the same service provider API as the secure self-paymentprocess. In particular, the personal shopper software module utilizesthe communication capabilities of the consumer mobile device to send amessage to the web API of the service provider network indicating theconsumer's choice. The web API of the service provider network respondsby processing the message from the personal shopper software module andgenerating one or more messages to be pushed to the retailerverification apps operating on retailer mobile devices and POS systemsindicating the consumer's choice.

In one embodiment, a method of identifying retail associates requiresall retail sales associates to carry a QR-coded business card or form,or have their personal associate QR code displayed on their retailerdevice. If at a point in the shopping trip, an associate does provideassistance, and if the consumer accepts the option, using theself-payment app the consumer can scan a sales associate-specific QRcode. Upon scanning the sales associate's specific QR code, the secureself-payment application provides the consumer with the option to leavea comment or fill out a consumer satisfaction survey at a later time. Inthis case, the consumer satisfaction survey, may be sent to theretailer's eCommerce website, POS system, store manager's email or otheronline repository. This feature also allows the retailer to trackpurchases attributable to specific sales associates.

Consumer Visit Alert. Using the consumer visit alert option within thesecure self-payment application, consumers may make an appointment tovisit a store to pick up items that were previously selected in-app.Upon selecting the option to set up a consumer visit, the secureself-payment application provides the consumer with the ability toselect a specific date, time, location and personal sales associate.Upon making an appointment via the customer visit alert module, thesecure self-payment application sends a request through the serviceprovider's web API to the retailer's electronic device running thecompanion retailer verification app or network. The retail associate maythen reply back with an “available” or “not available” response. If theretail associate is available at the requested time, the web API maysend back a confirmation to the secure self-payment application and theconsumer may then be guaranteed that a sales associate will be able tomeet with them to provide all services without having to wait.

In one embodiment, when a consumer creates an appointment using thesecure self-payment application, the web API may send the salesassociate or retailer a “Customer Visit Alert” to the retailerelectronic device. This alert may contain information such as the nameof the consumer, the selected items, and the date and time of theconsumer's expected arrival.

The consumer visit alert features are provided via a consumer visitalert software module that includes the functionality needed to carryout the above steps. This module prompts both consumer and retailassociate to input their request or reply. This module uses a similar orsame service provider API as the secure self-payment process. Inparticular, the consumer visit alert module utilizes the communicationcapabilities of the mobile device to send a message to the serviceprovider's web API so that it may be routed properly to the receivingretailer or consumer device.

Product Description and Reviews. The web API may connect to a thirdparty database that stores reviews or descriptions of the item that theconsumer has identified in-app. The item information and reviewdatabases may be separate entities and may be stored with either theservice provider, retailer, or require a third-party API or connectionto an information service. Specific examples of third party reviewplatforms that provide an API for integration into systems such as thesecure self-payment system include PowerReviews and BazaarVoice.

In one embodiment, the review platforms may serve to provide theconsumer with additional user generated content relating to the producthe or she is interested in.

In another embodiment, the consumer may be able to interact with theitem information or reviews service by submitting his or her own contentwhich may then be viewed by other consumers.

The product review features are provided via a reviews module thatincludes the functionality needed to carry out the required embodiment.This module will prompt the consumer to view reviews as well as providean option for submitting his or her own thoughts on the product. It isintended that the reviews feature is used as a method of viewingadditional user generated information about a product that is not storedwith the retailer or an item information database. This will likelyrequire the reviews module to make contact with a third-party reviewplatform web API for retrieval and submission of reviews.

Share Item Over Social. Networks. The secure self-payment applicationmay provide the consumer with an option to select a social networkingfunction so that information may be posted on his or her profile onsocial networks such as Facebook, Twitter, Pinterest or others. Thesecure self-payment application will make use of third-party socialnetwork APIs as well as au in-app interface for this function. Using theinterface displayed in-app on the consumer's device, the consumer maypost information including the price, product name, an image of one ormore items, and/or images of themselves holding or wearing the item(s),and any other identifiers.

The social media features are provided via a social media module thatincludes the functionality needed to carry out the required task. It maybe that one, some, or all social media sites mentioned above aresupported by the retailer or the secure self-payment application at anygiven time. As each social media site provides its own readily availablemobile API, the social media module will select the proper API to useand display the correct interface. The social media module may alsoconnect with the consumer profile 502 to retrieve the consumer'susername and password for faster access to his or her social mediaaccount.

Inventory Tag Removal and Bagging. The secure self-payment applicationdisplays an option that allows the consumer to request item anti-thefttag deactivation, shopping bags or help with heavy items. This requiresa connection to store inventory 504 and requires that the retailerinternally mark items in its software database which have an inventorytag or may be too heavy too lift. The service provider API retrievesthis information and displays it to the consumer as he or she retrievesthe product information for view on the screen of his or her device.

In one embodiment, the service provider web API sends a message to theretailer mobile device running the companion retailer verification appthat a consumer needs assistance with tag deactivation and may provide alocution where the consumer is by accessing the consumer device locationservices component.

In another embodiment, the consumer may be directed to a designatedstore, associate or service desk via an in-app message.

The tag removal, bagging and assistance features are provided via asoftware module that includes the functionality needed to carry out therequired task. It may be that a retailer does not have the requiredresources to internally flag items in its 504 database as heavy orneeding deactivation. When possible, the service provider API wouldretrieve the necessary information from the retailer database and 504and display the relevant flags on the consumer's mobile device in-app.

Additional Embodiments

An alternate use of the invention is based-around a two-capture processthat may be used to ensure that only an authorized device can use a codeto purchase items. In the preferred embodiment of this alternate use,this two-capture process can only begin when the consumer using thedevice knows a PIN or password for the consumer application. Forclarity, and in accordance with industry nomenclature we refer to thisalternate use as a mobile wallet. This alternate use does not includethe consumer adding items to a virtual cart in a physical store butrather the consumer would shop in a regular fashion by selecting itemsin store and bringing them to a cash desk.

For this service provider mobile wallet, a consumer signs-up for theservice provider and is provided with a consumer-specific QR code whichrepresents a consumer-specific string used for identification of thedevice and consumer. In the preferred embodiment, this consumer QR codeis unique by device-consumer pair but may vary across the consumer'smultiple devices or if multiple consumers are using the same device.After creating an account the consumer could then use his or her mobilewallet as follows.

The consumer engages in a traditional in-store shopping experience andbrings the items he or she wishes to purchase to the retailers point ofsale (POS) system.

The retail associate/cashier enters the presented items into theretailer's POS system and builds a corresponding purchase receipt, oftenby scanning the barcode on the items presented by the customer.

The consumer elects to pay with the service provider's alternateself-payment method. The retail associate confirms this selection ofpayment method on the POS or retailer mobile electronic device. Thisconfirmation readies the retailer's capturing device to capture theconsumer/device-specific QR code displayed on the consumer mobiledevice.

The consumer opens the service provider technology to the paymentscreen, establishing a network connection to the service provider. Thisnetwork connection is the connection 112 in FIG. 1 and FIG. 1A. Thisscreen initially displays the consumer/device specific QR code.

The consumer/device specific QR code is captured by the retailerverification device as embodied by the physical real world connection110 in FIG. 1 and FIG. 1A.

The retailer POS sends the customer and device pair string representedby the QR code along with the transaction details to the serviceprovider by a regularly established connection 114 (see FIG. 1 and FIG.1A).

The self-payment service provider processes the received information,and sends a payment authorization request to the payment processorcorresponding to the retailer's specific payment processor.

The payment processor receives a payment authorization request andprocesses that request, resulting in either a granted authorization oran error code. In the event of an error code, the code and anycorresponding information is sent to the service provider, and then toone or both of the consumer and the retailer with appropriate additionalinformation, depending on the preferences of the service provider. Thereceipt of an error code leads to either termination of the process or arestart.

In the event of a granted authorization, the service provider is sentthe success message from the payment processor.

The service provider then generates a companion transaction-specific andunique QR code for the consumer and the specific device. Thetransaction-specific unique QR code is sent to the consumer device bylook-up of the appropriate open connection for response.

The consumer device receives the transaction-specific QR code andupdates its currently displayed payment screen display to show the newimage. Note that the new QR.-code will never arrive at the consumerdevice unless the consumer has a valid device for the customer-devicepair code as the service provider server can check the device identifierand other properties to ensure the code is only sent to a valid device.In the event the code is not received the retailer can abort or restartthe process. A warning may also be sent to the consumer or retailerdevice.

The retailer captures the transaction-specific QR code directly from theconsumer's device. This transaction specific code contains averification key confirming that the real world device is notfraudulent.

The retailer capturing device processes the transaction-specific QR codeand sends the information collected by capturing thetransaction-specific QR code to the service provider server.

If a matching transaction-specific QR code is found on the serviceprovider server, for this specific transaction, the process continues.If a matching transaction-specific QR code is not found, the serviceprovider sends a warning message back to the retailer and/or theconsumer and either or both parties may abort or restart the process.

The service provider server then sends the payment processor server therequest to complete the previously authorized transaction.

The payment processor attempts to complete the transaction, resulting ineither a successful transaction or an error code. Upon an error code,the service provider will send appropriate notifications to the retaileror retailer and consumer devices, and will most likely abort thetransaction.

In the event of a successful transaction by the payment processor, theservice provider notifies all parties. At this point, thetransaction-specific QR code is marked as used by the service providerand no longer works to provide payment. The retailer and/or serviceprovider may store the transaction-specific QR code information to beable to capture again in the future for processing returns in a mannersimilar to that described in the Process Return flow 324. The net resultof this process is a dual capture solution for a mobile wallet, wherethe first scan initiates an authentication check, and the second captureverifies the consumer, by confirming the self-payment mobile walletservice provider has audited the consumer-device pairing and currentconnection. Note that no sensitive information is directly exchanged:the consumer/device QR code only works on that specific device so itcannot be used on another device, while the unique transaction code willonly work for the exact purchase that is uniquely identified in thatretailers POS. The above steps need not occur in the particular orderlisted unless otherwise stated.

The invention can be implemented in digital electronic circuitry, or incomputer hardware, firmware, software, or in combinations of them. Theinvention can he implemented as a computer program product, i.e., acomputer program tangibly embodied in an information carrier, e.g., in amachine readable storage device or in a propagated signal, for executionby, or to control the operation of, data processing apparatus, e.g., aprogrammable processor, a computer, or multiple computers. A computerprogram can be written in any form of programming language, includingcompiled or interpreted languages, and it can be deployed in any form,including as a stand alone program or as a module, component,subroutine, or other unit suitable for use in a computing environment. Acomputer program can be deployed to be executed on one computer or onmultiple computers at one site or distributed across multiple sites andinterconnected by a communication network.

Method steps of the invention can be performed by one or moreprogrammable processors executing a computer program to performfunctions of the invention by operating on input data and generatingoutput. Method steps can also be performed by, and apparatus of theinvention can be implemented as, special purpose logic circuitry, e.g.,an FPGA (field programmable gate array) or an ASIC (application specificintegrated circuit).

Processors suitable for the execution of a computer program include, byway of example, both general and special purpose microprocessors, andany one or more processors of any kind of digital computer. Generally, aprocessor will receive instructions and data from a read only memory ora random access memory or both. The essential elements of a computer area processor for executing instructions and one or more memory devicesfor storing instructions and data. Generally, computer will alsoinclude, or be operatively coupled to receive data from or transfer datato, or both, one or more mass storage devices for storing data, e.g.,magnetic, magneto optical disks, or optical disks. Information carrierssuitable for embodying computer program instructions and data includeall forms of non volatile memory, including by way of examplesemiconductor memory devices, e.g., EPROM, EEPROM, and flash memorydevices; magnetic disks, e.g., internal hard disks or removable disks;magneto optical disks; and CD ROM and DVD-ROM disks. The processor andthe memory can be supplemented by, or incorporated in special purposelogic circuitry.

All references, including publications, patent applications, andpatents, cited herein are hereby incorporated by reference to the sameextent as if each reference were individually and specifically indicatedto be incorporated by reference and Were set forth in its entiretyherein.

The use of the terms “a” and “an” and “the” and similar references inthe context of this disclosure (especially in the context of thefollowing claims) are to be construed to cover both the singular and theplural, unless otherwise indicated herein or clearly contradicted bycontext. All methods described herein can be performed in any suitableorder unless otherwise indicated herein or otherwise clearlycontradicted by context. The use of any and all examples, or exemplarylanguage (e.g., such as, preferred, preferably) provided herein, isintended merely to further illustrate the content of the disclosure anddoes not pose a limitation on the scope of the claims. No language inthe specification should be construed as indicating any non-claimedelement as essential to the practice of the present disclosure.

Multiple embodiments are described herein, including the best mode knownto the inventors for practicing the claimed invention. Of these,variations of the disclosed embodiments will become apparent to hose ofordinary skill in the art upon reading the foregoing disclosure. Theinventors expect skilled artisans to employ such variations asappropriate (e.g., altering or combining features or embodiments), andthe inventors intend for the invention to be practiced otherwise than asspecifically described herein.

Accordingly, this invention includes all modifications and equivalentsof the subject matter recited in the claims appended hereto as permittedby applicable law. Moreover, any combination of the above describedelements in all possible variations thereof is encompassed by theinvention unless otherwise indicated herein or otherwise clearlycontradicted by context.

The use of individual numerical values are stated as approximations asthough the values were preceded by the word “about” or “approximately.”Similarly, the numerical values in the various ranges specified in thisapplication, unless expressly indicated otherwise, are stated asapproximations as though the minimum and maximum values within thestated ranges were both preceded by the word “about” or “approximately.”In this manner, variations above and below the stated ranges can be usedto achieve substantially the same results as values within the ranges.As used herein, the terms “about” and “approximately” when referring toa numerical value shall have their plain and ordinary meanings to aperson of ordinary skill in the art to which the disclosed subjectmatter is most closely related or the art relevant to the range orelement at issue. The amount of broadening from the strict numericalboundary depends upon many factors. For example, some of the factorswhich may be considered include the criticality of the element and/orthe effect a given amount of variation will have on the performance ofthe claimed subject matter, as well as other considerations known tothose of skill in the art. As used herein, the use of differing amountsof significant digits for different numerical values is not meant tolimit how the use of the words “about” or “approximately” will serve tobroaden a particular numerical value or range. Thus, as a generalmatter, “about” or “approximately” broaden the numerical value. Also,the disclosure of ranges is intended as a continuous range includingevery value between the minimum and maximum values plus the broadeningof the range afforded by the use of the term “about” or “approximately,”Thus, recitation of ranges of values herein are merely intended to serveas a shorthand method of referring individually to each separate valuefalling within the range, unless otherwise indicated herein, and eachseparate value is incorporated into the specification as if it wereindividually recited herein.

It is to be understood that any ranges, ratios and ranges of ratios thatcan be formed by, or derived from, any of the data disclosed hereinrepresent further embodiments of the present disclosure and are includedas part of the disclosure as though they were explicitly set forth. Thisincludes ranges that can be formed that do or do not include a finiteupper and/or lower boundary. Accordingly, a person of ordinary skill inthe art most closely related to a particular range, ratio or range ofratios will appreciate that such values are unambiguously derivable fromthe data presented herein.

1.-7. (canceled)
 8. A system comprising: a server comprising one or moreprocessors and a non-transitory storage medium in communication with theone or more processors, the non-transitory storage medium storinginstructions which, when executed by the one or more processors, causethe one or more processors to: receive a first set of data from a mobiledevice, the first set of data comprising identifying information for oneor more goods or services to be purchased; receive a second set of datafrom the mobile device, the second set of data identifying a paymentmethod related to the purchase of the one or more goods or services;transmit a request for payment authorization to a payment processingsystem, the request for payment identifying the payment method; receivefrom the payment processing system a response to the request for paymentauthorization indicating whether the request for payment authorizationwas approved; create, in response to an approved request for paymentauthorization, a data record in a database, the data record representinga completed purchase of the one or more goods or services; generate, inresponse to the completed purchase of the one or more goods or servicesvia the identified payment method, a unique token, the unique tokenassociated with said data record; transmit the unique token to themobile device, the mobile device configured to display the unique toenable the retailer electronic device to scan the unique token and toverify the purchase of the one or more goods or services; receive fromthe retailer electronic device a request to verify the unique token inorder to confirm the purchase of the goods or services; and transmit tothe retailer electronic device information indicating whether the uniquetoken is valid.
 9. The system of claim 8, wherein the data recordincludes the following data: the goods or services purchased, the methodof payment used to purchase the goods or services, the date and time ofthe purchase, the retailer name, the location of the transaction, and aconsumer ID.
 10. The system of claim 8, wherein the unique token is inthe form of a URL link or a portion thereof.
 11. The system of claim 8,wherein the step of generating in response to the purchase of said oneor more goods or services via the identified payment means a uniquetoken comprises the step of embedding in the token a link to the datarecord.
 12. The system of claim 8, wherein the non-transitory storagemedium of the server has further instructions thereon which, whenexecuted by the one or more processors, cause the one more processors toexecute the following steps: determining whether any of the one or moregoods or services identified in the first set of data are currentlyunavailable for purchase; and transmitting a notification to the mobiledevice indicating whether any of the one or more goods or servicesidentified in the first set of data are currently unavailable forpurchase.
 13. The system of claim 8, wherein the first set of data isinput by the consumer when the consumer is outside of the retailerlocation containing the goods and services, and wherein thenon-transitory storage medium of the server has further instructionsthereon which, when executed by the one or more processors, cause theone more processors to execute the following steps: creating a dataentry in the data record to indicate the portion of the goods identifiedin the first set of data that have already been collected from theretailer by the consumer.
 14. The system of claim 8, further comprisingan electronic device capable of communicating with the server, saidelectronic device comprising: one or more processors; a wirelesstransceiver operable by said one or more processors; and anon-transitory storage medium in communication with the one or moreprocessors of the electronic device, said non-transitory storage mediumhaving instructions thereon which, when executed by the one or moreprocessors, cause the one or more processors to execute the steps of:transmitting a request to the mobile device for the unique token whenthe electronic device is brought into sufficient proximity of the mobiledevice to permit wireless communication between the electronic deviceand the mobile device; transmitting said unique token to the server;receiving from the server an indication of whether said unique tokencommunicated from the mobile device is valid; and displaying via theelectronic device whether said unique token communicated from the mobiledevice is valid.
 15. The system of claim 8, wherein the non-transitorystorage medium of the server has further instructions thereon which,when executed by the one or more processors of the server, cause the onemore processors of the server to execute the following steps: comparingthe unique token to entries in a table containing valid purchaseinformation; and determining whether the unique token matches an entryin the table containing valid purchase information.
 16. The system ofclaim 8, wherein the unique token is in the form of a URL string. 17.The system of claim 8, wherein the mobile device is equipped withlocation service functionality and wherein the non-transitory storagemedium of the server has further instructions thereon which, whenexecuted by the one or more processors of the server, cause the one moreprocessors of the server to execute the following steps: receiving fromthe mobile device an indication that the mobile device is located near aretailer location; and transmitting to the mobile device a notificationthat the device is located in or near a retailer location.
 18. Thesystem of claim 17, wherein the step of receiving from the mobile devicean indication that the mobile device is located near a retailer locationis triggered by the mobile device breaching a geofence of the retaileror connecting to a wireless network of the retailer.
 19. The system ofclaim 14, wherein transmitting said unique token to the mobile devicefor use by the consumer to verify to the retailer the purchase of saidone or more goods or services by communicating said unique token to theelectronic device includes the retailer device optically scanning animage on the mobile device.
 20. The system of claim 8, wherein thepayment means includes a coupon.
 21. The system of claim 14, wherein theelectronic device includes a barcode scanner.